CTRIO2 _Out0.OutputVelocity polarity?

[BobO]

Unless there is a parameter setting way off in left field the CTRIO has a problem.  You can't wait until you get to the stop sign to apply the brakes.  Going 2 mph to make it work isn't a fix.

The module is fine. It wasn't designed to do what you are doing and I have no idea whether it can be made to work. I hate suggesting that someone not use my products, but you are coloring way outside the lines and it may simply not work.

BobO, can you check the output (OutputVelocity) as it approaches the target to see if it starts slowing?

Stick it in a trend view.

I just thought of something.  I read input A from the encoder to get the frequency.  I'm using 4X input on the encoder.  Do I need to multiply my reading by 4?  I think each edge of both signals are creating an input pulse.

I need to change the encoder/output ratio!

If your 2.5x ratio was comparing the actual output frequency to the actual input frequency, then the 4x encoder has already been resolved.

I suspect that your issue is related to lag in the VFD. You said the ramps have been disabled, but even so I seriously doubt that a VFD has zero latency. The CTRIO was designed to control position as would be used with a servo or stepper...not a velocity on a VFD.

[BobO]

It's a shame we don't have a simple, dedicated solution of hardware/software for these low bandwidth positioning applications.

Yeah (while bearing in mind that I've never done an app like this with a CTRIO) it kinda feels like the wrong tool.  I've done it in PLC motion modules that have analog outputs that can be configured as velocity or torque (often torque works better).   Since something like that isn't available in Do-More, I'd lean towards an external motion controller with analog output to feed to the VFD, possibly experiment with having the VFD in torque mode, and just have the PLC issue position commands to the loop controller via Modbus.

This actually gives me an idea for an instruction. If these kind of analog-out-driving-VFD-resolving-position-by-encoder apps are pretty common, I'm sure that we could create a PID derivative (no pun intended) that would work with an encoder input and an analog output to resolve a position or velocity. Since you are controlling a fairly sloppy VFD with an analog output, I would think that controlling at the PLC scan time wouldn't be too much of a limitation. With encoder input, I'd say we could do a passable job if high speed or precision wasn't required.

[BobO]

And ERokc...

A great test would be to do step changes in velocity and look at the difference between the target and actual velocities. Calculate the error and plot it in a trend view. I suspect that you will see quite a bit of lag between the change in the analog control value and the input frequency. Reducing accel/decel to minimize the effect of lag might help, and those step changes would be the best way to quantify the affects of various tuning changes.

[Controls Guy]

Yeah, that's the other thing.  If you're going to do this you don't want to buy the cheapest VFD you can find.  Maybe talk to your VFD distributor about the right choice for positioning.  Don't skimp on motor or drive size either.

[b_carlton]

As Gene Bond mentioned I use (square root of the distance from target * empirically derived constant) for the output. The 'constant' is determined by trying the system and watching the approach. Just start low and work upward. Minimal overshoot vs positioning speed. The system turns off once the target is reached/crossed. No holding position. Friction is fine.

The output is limited on the top (max vfd speed) and bottom end (min creep speed). For basic positioning (we get about 1/50th of an inch using a ball screw and acme shaft) it's inexpensive. Though we always position from one direction. For finer (and faster) applications of course we use an actual servo system.

I know, I should be thrown out of any association of controls people. (Come to think of it, I'm not in any.) But it's like my definition of 'real time' control. 'Does it work in time? OK then.'

[BobO]

As Gene Bond mentioned I use (square root of the distance from target * empirically derived constant) for the output. The 'constant' is determined by trying the system and watching the approach. Just start low and work upward. Minimal overshoot vs positioning speed. The system turns off once the target is reached/crossed. No holding position. Friction is fine.

The output is limited on the top (max vfd speed) and bottom end (min creep speed). For basic positioning (we get about 1/50th of an inch using a ball screw and acme shaft) it's inexpensive. Though we always position from one direction. For finer (and faster) applications of course we use an actual servo system.

I know, I should be thrown out of any association of controls people. (Come to think of it, I'm not in any.) But it's like my definition of 'real time' control. 'Does it work in time? OK then.'

It actually sounds pretty practical to me Bernie. You are basically describing a PID loop, using only the P term and the square root of error. The empirically derived constant is simply gain. Sounds like a totally legit way to do it.

Which brings me back to my earlier point. The CTRIO uses a very specific method of closing the loop that is heavily dependent on being used with servos or steppers. I doubt that it will work very well with a VFD.

[Controls Guy]

Bernie, I agree with BobO.  I don't see anything wrong with that for any app where it does the job.

[BobO]

For chuckles, I coded up Bernie's approach in Do-more, using a CTRIO2 in axis-based DynaVel mode to simulate a VFD. Worked very well once tuned. The key thing I noticed was that the slower the response of the velocity profile, the harder it was to avoid overshoots. Which, in turn, tells me that the greater the latency of the analog interface of the VFD, the harder it will be to get a stable result. As Bernie mentioned, It will essentially come down to a trade-off between positioning speed vs overshoot. The slower the VFD's response, the lower the max positioning speed. Other than that caveat, I think it would work great.

[ERokc]

I appreciate all of your inputs on my problem BUT NO ONE IS UNDERSTANDING THE PROBLEM.

Here's what is happening.
Starting up the output (OutputVelocity) ramps up as set in acceleration to the Max Hz and tops off.  The VFD moves the encoder.  The encoder value curves upward during acceleration then has a straight line upward slope when speed is constant.
The encoder value continues to climb and the output stays at Max UNTIL IT CROSSES THE TARGET value of the encoder where it then ramps down passing zero and going negative.  The VFD now reverses as instructed and it does the same thing in reverse, never to stop on the target.

You have to slow down BEFORE you get to the target!  Not only before but in time for deceleration to arrive at zero speed coincident with the target position.  CTRIO is not doing that!

It's like driving your car to an intersection and applying the brakes when you get even with the stop sign.  The car runs into the intersection.  It then reverses and as it backs to the stop sign, brakes when even with the sign.  It's never going to get stopped at the sign (target).

The VFD is following the signal.  It's not getting a correct signal!

Give me DETAILS on how to capture my Trend screen and send it to this forum.  I have the Trend set up, just need to capture and send it so you can see what I'm talking about.

[BobO]

I appreciate all of your inputs on my problem BUT NO ONE IS UNDERSTANDING THE PROBLEM.

Trust me, I fully understand what you are saying and what you are seeing. I also know unequivocally that the module does decel before the target and will hit the exact target to within just a few encoder counts...when it is used with steppers or servos as designed. So my quandary is that you are using the module in a manner completely outside its design intent and insisting that it isn't working right, yet I know it works right when used as designed. I hope you can appreciate the awkward spot that puts me in.

I was trying to explain that when driving a VFD in the manner that you are doing, any latency in the VFD's response as compared to the CTRIO's request could cause an overshoot due to the accel/decel portions of the move taking far more time (and counts) than what was calculated by the module, resulting in the positioning move being much longer than actually required. In an effort to prove or disprove that point, I suggested that you compare the requested output velocity to the resulting input velocity in real time, calculating the error between the two. I think there is a very good chance that the VFD is accelerating quite a bit slower than the CTRIO is asking it to. Since the CTRIO's closed loop mode isn't really a loop in the conventional sense, it won't adjust on the fly like I think you need it to. It does make small real time tweeks on the decel, but it is expecting the velocity to be exactly what it thinks it is...not whatever the VFD actually gives it. Any disconnect between what it thinks is happening and what really is happening could easily cause what you are describing.

If that is the case, one of the alternate approaches that we recommended might get you where you need to be. It is also possible that the CTRIO can still do it, but part of the process of tuning it is to understand what the latency is. It may be that adjusting the CTRIO's accel/decel to match what the VFD is actually capable of will fix 90% of the problem, but until we know what that is, we're kinda sunk.

[ERokc]

I appreciate your help very much and you are giving me a better understanding of what CTRIO can and can't do. Tell me if this is correct.

CTRIO calculates the number of pulses to reach the target.
Applies the rates for the ramps.
Sends that stream of pulses to the output.
Looks for error on decel and adjusts what it can.

I can see where a mismatch in what it's expecting would cause it to miss the target.
Seems like the VFD/encoder input is running too fast and arriving at the target before the pulse stream is ready for decel.  If it was running too slow seems like decel would come early, not late.  That might be a clue to which direction to adjust.

In any case I have not adjusted the output/encoder scale as mentioned previously but hope to get back on it in a day or two.  Are you saying if I can get the VFD to match what CTRIO is expecting close enough it should work?  Close enough for it to make adjustments as it decels?

My application is not demanding like controlling a mill table would be.  It does not need high accel or decl.  Position can be ±60 counts.  I don't know if that will be difficult until I try it. Hope to find out soon.  If I need to move close but short of the final target then make a slower short move to get there that would be fine.

I will plot the output against the encoder input for a position move and see how much error there is.  Can I record a trend, save it in a file and send it for you to see?  I'm headed to Designer to find out.

[BobO]

You know...I've completely confused myself. There was one of the profiles that worked exactly like that...it only did slight tweeks on the decel to arrive at 0Hz at the target position, but I was thinking that TrapPlus was built on a much more dynamic profile that does continually re-compute the distance to the target. I know for certain that the axis mode functions use the dynamic code, and CTAXDYNP is dynamic enough to have it's target position changed on the fly. However, even in the case of the dynamic profiles, if the scale ratio is significantly wrong or if the accel/decel is considerably different that what the drive/motor will actually do, the calculated pulse counts produce a very wrong result that will cause the overshoots you are seeing...I've seen it many times, and it is almost always an improper ratio setting.

The only reason I'm not harping on the ratio is because I can easily see that the VFD could be causing issues 2 ways...by the CTRIO's accel/decel not matching what the drive is actually doing, or by there being some lag in responding to freq changes. The best way to get to the bottom of this would be to run a profile open loop...no encoder feedback...and compare the CTRIO's velocity and position out to the encoder input's velocity and position. I think we will learn a bunch from that, so I would really encourage you to so that experiment. If you do, please trend all four of those values, export the trend data, and get a copy to me...I'd like to look at it.

The key thing here is that we will do our best to help you make this work...you are not alone...but...you are definitely outside the norm here...so this might take some work.

[BobO]

I finally remember...I've been doing this too long...head full of mush sometimes.

The new profiles are completely dynamic and are computing the decel point constantly. If the decel appears to be running past the target upon arriving at 0Hz, it will increase the decel rate up to +25% to try to get stopped by the target position. It determines when to start the decel by computing the number of pulses it will require to get to 0Hz from the current speed. When the number of pulses remaining to the target is less than or equal to the decel count from the current freq, it will start the decel, and then will do the additional adjustment on the way down. If the actual rate of deceleration is not in agreement with the prediction, and required rate is more than 25% different from actual, it will overshoot.

So to summarize, if the scale ratio is wrong, the decel prediction will be wrong. If the actual rate that the VFD decels is significantly different than what the CTRIO is requesting, the prediction will be wrong. If there is considerable lag in the VFD's response, the prediction will be wrong. If any prediction is off by more than 25%, it will end up overshooting. My money is on one or more of those three being at issue.

[ERokc]

SUCCESS!

It's hitting the target.  I was right about the encoder being much faster than CTRIO was expecting so I stepped the scale until I got good results.  You were right, the scale is way off. I don't know why my calculations were not correct and that bothers me.  I need to get the scale value correct, not just close enough.

Here is what I did. 1000Hz out runs the encoder Ch1A input at 400Hz as read by FREQCNT.  I have the encoder set for 4X so that's 1600Hz input. 1000/1600 = .625 (10/16) What works is .15 (1/6)   I need to put a scope on the signals to see exactly what they are. Something's wrong, I need to find it!

The waveforms are EXACTLY what they should be. My test setup does not get up to full speed and half way to the target the output starts a downward slope as it should.  Hits within 90 counts.  That will work.

I discovered a problem not in the documentation for CTRUNPOS.  I have it set a bit on error.  My program does not clear that bit.  When CTRUNPOS is run with the bit set it delays for 10 seconds, resets the bit then physically runs to completion BUT does not set "On Success". It stalls in the Stage waiting to jump on success.  If I clear the error bit first it runs correctly.  That needs to be noted or fixed whatever is appropriate.  I think it should clear the bit on execution then run to completion.

Thank you for looking into my problem.  Last year when I was planning the project design I inquired about this application.  You said you thought it would work.  I was not going to rub it in your face but don't need to. Your were right, it works.  I still need to tweak it and set up the rest of the moves.  I need to see how loading will effect it and if there is a temperature effect.  The machine will not be temperature controlled.

I am sooo pleased. I was beginning to worry. I like what I see.  Do-more is a good system.  I'm fortunate to have done my first PLC project on it.  Do-more came out during the middle of my PLC class. I still remember the Do-more popup on the screen that I followed through on.  Keep up the good work.

BTW,I didn't get instruction I asked for on saving a Trend and sending it.  Do use FILE, EXPORT, PROJECT?.. I would like to save waveforms but can't determine how.

[BobO]

SUCCESS!

Glad to hear it!

It's hitting the target.  I was right about the encoder being much faster than CTRIO was expecting so I stepped the scale until I got good results.  You were right, the scale is way off. I don't know why my calculations were not correct and that bothers me.  I need to get the scale value correct, not just close enough.

Here is what I did. 1000Hz out runs the encoder Ch1A input at 400Hz as read by FREQCNT.  I have the encoder set for 4X so that's 1600Hz input. 1000/1600 = .625 (10/16) What works is .15 (1/6)   I need to put a scope on the signals to see exactly what they are. Something's wrong, I need to find it!

I'm confused. Are you using the FREQCNT instruction? There is no way a PLC instruction can do that accurately, the scan is too slow. To accurately determine the input frequency of a CTRIO input channel, use the CTRIO's Rate scaling option on that channel. You could also also feed the channel's .iReg1 input into a SLOPE instruction, but the CTRIO will automatically do the work for you...and far more accurately. Be aware that if you use Rate scaling, iReg1 becomes the scaled data (if integer) and the raw position gets moved to iReg2.

So yes, you are right and this is the core of the problem...your actual encoder speed is much higher than what you thought and the resulting scale ratio was wrong. As I mentioned before, that has been the issue in every case to date...and the only reason I didn't push it was due to concern that the VFD was introducing new unknowns.

I discovered a problem not in the documentation for CTRUNPOS.  I have it set a bit on error.  My program does not clear that bit.  When CTRUNPOS is run with the bit set it delays for 10 seconds, resets the bit then physically runs to completion BUT does not set "On Success". It stalls in the Stage waiting to jump on success.  If I clear the error bit first it runs correctly.  That needs to be noted or fixed whatever is appropriate.  I think it should clear the bit on execution then run to completion.

I'm a bit skeptical here. The first thing the instruction does is to clear both the Success and Error bits, and the program doesn't need to clear it. That is a standard methodology we use with every device centric instruction. It is well tested. I just tried a CTRUNPOS with bits for success and error, and also tried it with a transition to stage on success and a bit for error. In both cases, with the error bit set, it immediately cleared the bit, ran to completion, and set the success.

Remember that CTRUNPOS doesn't execute, at all, if the stage it is in is disabled. You might also check the xref to make sure that the error bit isn't being used somewhere else in the program in some way that might be conflicting with the CTRUNPOS box.

Thank you for looking into my problem.  Last year when I was planning the project design I inquired about this application.  You said you thought it would work.  I was not going to rub it in your face but don't need to. Your were right, it works.  I still need to tweak it and set up the rest of the moves.  I need to see how loading will effect it and if there is a temperature effect.  The machine will not be temperature controlled.

I just reread my responses to your initial request. I would hardly consider what I said to be a glowing endorsement of the concept, I although I allowed that it might work. I also said that the VFD might create some latency that would prove to be a problem. Nevertheless, it did work...and I'm very happy for you.

BTW,I didn't get instruction I asked for on saving a Trend and sending it.  Do use FILE, EXPORT, PROJECT?.. I would like to save waveforms but can't determine how.

On the toolbar of the Trend View, there are options for exporting ("Exp") and streaming a running capture to disk ("Rec"). The export option gives you the ability to specify how the data is generated. Both of these options generate text data files that can be loaded into a spreadsheet for post processing or viewing.

You can also do screen grabs with a screen capture tool. I personally like Screen Hunter.