Host Engineering Forum
General Category => CTRIO and CTRIO2 => Topic started by: ERokc on July 20, 2013, 02:56:21 PM
-
Does it go negative when CTRIO reverses?
-
I don't for sure know the answer to your question, but....
Velocity is speed, so 0 movement = 0 velocity, any movement in either direction will INCREASE the velocity. Even in reverse, velocity is not negative. On the other hand, POSITION can go positive or negative depending on direction.
-
If you back your car at 15mph that's negative compared to forward. +- usually defines direction.
What I'm trying to do is convert CTRIO frequency out to 4-20ma current to signal a VFD using F2-02DA-1 module. I set the zero speed of the VFD at 50% so I have reverse 0-49 and forward 51 to 100. If velocity goes negative with reverse then the conversion would simply be offset by 50% for STOP and scaled for MAX. I don't want to use FWD/REV on the VFD. I want RUN/STOP. I get a more positive control of stopping should something go wrong. Clearing RUN/STOP bit will stop it regardless what the analog output is.
If OutputVelocity does not go negative I need to look for another way to convert to current.
-
There is a direction flag. It is very simple to create a negative velocity.
-
OutputVelocity does go negative so OutputVelocity+2005 sent to A/D current out drives the VFD both directions.
Now the problem became overshoot and oscillating (hunting) around the Target Position.
CTRIO does not slow as it approaches the target and shoots past then the output starts going the other direction.
I increased the deceleration rate by 10X and it overshot the deadband (1000) by 3000 and completed. I store the count at completion so I know where it was when it thought it was through.
Target 12000, completed 11339, stopped at 15751. Why didn't it reverse back to the target?
I'm thinking maybe the deceleration rate brought the output to zero and the position was within the deadband so it completed. Next I will decrease the declaration and deadband. Deadband needs to be much smaller anyway. I think I'm in the TUNING mode. I'll report back what happens.
-
OutputVelocity does go negative...
Does it? Good. I wrote the CTRIO/2 code, as well as Do-more...you'd think I'd know this stuff. ::)
-
Now the problem became overshoot and oscillating (hunting) around the Target Position.
CTRIO does not slow as it approaches the target and shoots past then the output starts going the other direction.
I increased the deceleration rate by 10X and it overshot the deadband (1000) by 3000 and completed. I store the count at completion so I know where it was when it thought it was through.
Target 12000, completed 11339, stopped at 15751. Why didn't it reverse back to the target?
I'm thinking maybe the deceleration rate brought the output to zero and the position was within the deadband so it completed. Next I will decrease the declaration and deadband. Deadband needs to be much smaller anyway. I think I'm in the TUNING mode. I'll report back what happens.
You have a deadband, so I'm assuming that you are using closed loop mode with encoder input? It sounds like your encoder/stepper scale ratio may be wrong.
-
How many details can a programmer remember before a memory dump?
As usual I am doing unorthodox work so there's always something that will not work without looking for a method. This is one.
I'm using the OutputVelocity to write to a 4-20ma current input to a VFD. That works. The analog input is 0 to 4095 with 2005 where the VFD is stopped. ±OutputVelocity + 2005 = speed.
I set the min-max frequency to 30 - 1000. Accel 1000pss Decel 5000pss Anything faster hunts, slower stops within a WIDE deadband 1000 but inertia carries it past the target 12000.
I left the encoder/stepper scale at 1. Don't know what it should be because I'm not driving a stepper. I intend to scale the encoder to 1000 per inch of travel. It's ratio is close to that with the gearing.
How do I come up with a ratio that is useful for the CTRIO2? The waveform shows no decrease in velocity as it approaches the target. Only after crossing the target does it start reversing direction. There may be a hint of change just before the target, hard to tell.
Should I approximate the encoder frequency to output frequency to the VFD as the ratio?
-
If you are outputting a pulse stream to move the motor, it doesn't matter whether it is a stepper or not, there will still be a ratio between each output pulse and each encoder input pulse. If you don't know what the proper ratio is, take the axis out of closed loop mode, then do a move of 10000 pulses...or whatever works... then look at how much the encoder moves. That will give you good numbers to determine the ratio. Until you set that right everything else is irrelevant.
-
BobO:
Realize he is using a frequency to analog conversion to output to a VFD, rather than a stepper/servo, so outputting a certain number of pulses is not as relevant as the frequency...
Although I've not used DoMore for this, I have used DS and others for this type application. It's a shame we don't have a simple, dedicated solution of hardware/software for these low bandwidth positioning applications.
My solutions in the past have been much like BCarlton's. My biggest gripe has been all the math conversions one must go through to get everything tied together. I am hopeful it's a thing of the past with DoMore. I have a couple jobs out there that should be coming in to try!
-
Then he may be using the wrong tool. The CTRIO outputs are not appropriate for this app. This sounds more like a PID app.
The CTRIO pulse profiles implement a straight proportial loop where the gain is the scale ratio. That may be an adequate loop, but he still has to set the ratio, and there is still a gain between the input and output.
-
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.
-
While there is not a locked step for step relationship with what I'm doing there is a ratio of output frequency to motor Hertz. I have taken out the ramps in the VFD control. It is responding to the ramps output by CTRIO. CTRIO is not ramping soon enough to stop on the target.
With OutputVelocity putting out 1000Hz the encoder is turning at 400Hz so I entered 2.5 as the ratio for the output/encoder scale.
My current setting allows it to finish w/o hunting but it overshoots as the motor is still running too fast as it crosses the target. I discovered how to expand the time line of the Trend window. The output does start downward about 1/16s before reaching the target position, way too late. The time scale is hard to read on the Trend graph.
What would cause it to not be comparing distance to go against speed? I will slow deceleration and see if that helps.
-
Changed max Hz from 1000 to 500 to 200 with ±accel set to 500 and got a complete in one shot.
This is about 1/10th the desired speed so I'm hoping to ramp it up.
I changed ± accel to 100 and had one overshoot then it returned to target. That tells me the ramp is related but it should not be. When deceleration is slow it should start slowing sooner. The VFD is following the signal, the frequency is not dropping near soon enough.
CTRIO is not looking ahead to start breaking and stop on target. Why?
Here is what I have set up,
CTRUNPOS with Trapezoid Plus Profile. Should I be using a different mode? Does CTAXCFG need to run? It looked like the profile covered everything.
-
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.
BobO, can you check the output (OutputVelocity) as it approaches the target to see if it starts slowing?
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!
-
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.
-
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.
-
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.
-
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.
-
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.'
-
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.
-
Bernie, I agree with BobO. I don't see anything wrong with that for any app where it does the job.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
While I'm thinking about it, the VFD lags the output by 150ms. That's measuring on the Trend screen. My new problem is the overshoot caused by coasting after CTRIO has reached the target. When it finishes I capture the count and it is within the deadband (100) but the encoder coasts 250 more. I have decreased the decel to get it that close. I may need to make it in two moves. I thought of that already. Any suggestions?
I cannot duplicate the problem I had with the error bit. I'm leaving it alone.
SLOPE gave me a frequency of 6329 with 1000Hz out which results in a scale of .158 My trial was real close at .15. It's working good.
About Trend, I would like to save the data and display it in the Trend screen off line from the PLC. Is that possible? The only files I see are the .txt
It would be handy to have the X&Y values displayed for the cursor position. That would aid in making measurements.
Thanks to all for your help. My machine now has predictable motion.
Before I start something that's not possible I have a question, will the preset table run its compares while the motion function is positioning? Now I'm going to add another control function, an actual stepper drive with no feedback. Strictly open ended. Can CTRIO run those three functions at the same time? H2-CTRIO2 is what I have.
-
It would be handy to have the X&Y values displayed for the cursor position. That would aid in making measurements.
Check Designer's status bar. Also, left click at any point in time. Both of these are useful in historic mode, scrolling with smaller time period windows of 1 second or 500ms.
-
While I'm thinking about it, the VFD lags the output by 150ms. That's measuring on the Trend screen. My new problem is the overshoot caused by coasting after CTRIO has reached the target. When it finishes I capture the count and it is within the deadband (100) but the encoder coasts 250 more. I have decreased the decel to get it that close. I may need to make it in two moves. I thought of that already. Any suggestions?
That doesn't surprise me at all. If you were to use a dynamic positioning profile, in axis mode or otherwise, and give it some time to settle after the initial .AtTarget indication, I think the module would correct it. If not, I would really consider the simple loop controller Bernie suggested.
SLOPE gave me a frequency of 6329 with 1000Hz out which results in a scale of .158 My trial was real close at .15. It's working good.
Good.
About Trend, I would like to save the data and display it in the Trend screen off line from the PLC. Is that possible? The only files I see are the .txt
Not currently. The text files can be imported into Excel and viewed in a graph, but currently we don't have any way to load the data back into the Trend view.
Before I start something that's not possible I have a question, will the preset table run its compares while the motion function is positioning? Now I'm going to add another control function, an actual stepper drive with no feedback. Strictly open ended. Can CTRIO run those three functions at the same time? H2-CTRIO2 is what I have.
Each pulse output function consumes two outputs, regardless of whether you are actually using them, which for the VFD you aren't. Preset tables are primarily there for firing discrete outputs, so the tables are actually loaded as output functions, but associated with a particular input function. Since your two pulse outputs will consume all four of your outputs, you will not be able to do a preset table and two pulse outputs at the same time. If the outputs were available, it would be no problem to load tables on the other two outputs while a pulse output is running.
Again, a simple square-root-of-error output controller for the VFD should do just fine, and would give you two spare outputs for doing presets. Otherwise, you can use two CTRIO2 modules...which of course would make me happiest...but that isn't the cheapest possible solution.
-
I need motion, preset output and stepper control at the same time. I have a full 6 module base and no room to expand to a 9. I do plan more than one machine so there's more purchases coming. I think I can get what I need using your suggestion, I'll discuss below.
My machine assembles one product unit then repeats. I need positioning to index to the start of the process. Semi-precision needed there. Discrete output terminals not used as VFD is driven with current output.
Preset table will not use output terminals either. It will step a DRUM to get an array of output positions.
Stepper control will use the output terminals so they are dedicated.
Given two of the functions don't have dedicated outputs I can have presets and motion just not at the same time. Don't need them at the same time if using "square-root-of-error controller". The motion during preset output just needs to run at operator selected speed and after completing a unit stop just before the home position. No precision needed there. This is a conveyor so if everything goes well it will not need to reverse direction although it can.
Is this Bernie's control you mentioned? I'm not smart enough to put that into instructions. Would you help. Does this control ramp up and down? Fill me in on the details, please. Maybe I should be asking Bernie for help on this. I'm guessing Bernie is b_carlton?
-
The motion controller Bernie mentioned is quite simple.
P = Current position
T = Target position
G = Gain factor
Out = Analog output to VFD
Out = sqrt(T - P) * G
In reality it will be a little more complicated than that, since you cannot take the square root of a negative number. You will also want to create a deadband, and will need logic to determine when you are at the target position. If I get a few free minutes, I'll try to throw together a sample app that implements this as a program block. It really isn't hard and would resolve your stability problem.
-
I don't see your reply with the program block but I copied it and I am ready to implement it. See if I understand it.
First MATH box TARGET is destination count.
POSITION is encoder counter.
Second MATH box determines if within DEADBAND, if not then = ERROR.
Third MATH Lessor of ERROR and 4000, ie. sets RawFreq to 4000 min
Does GAIN set the slope?
Forth MATH set direction
When ERROR is zero then delay and done.
Correct me where I'm wrong, please.
Will this reverse if it overshoots before the settling time?
I like it, it's simple.
Thanks
-
This is the entire contents of the RunToPosition program block.
The first MATH box computes raw error. 'Target' is the encoder position you want to be at. 'PositionIn' is the current encoder value.
The second MATH box compares absolute error to a specified deadband, setting 'Error' to 0 if inside the deadband, or uses RawError if outside. 'Deadband' is expressed in encoder units.
The third MATH box calculates the raw output frequency as sqrt(Error)*Gain. 'Gain' will be a float value determined empirically. If too high, the motor will oscillate around the target. If too low, it will take all day to get there. I also added a MIN(Freq, 4000) to limit to a max freq. Change 4000 to whatever you really want, or remove the limit.
The fourth MATH box, just adds the sign back to the RawFreq, since due to the square root, can't be negative. You'll need to scale the Freq back into your analog output value, but that should work just like it does with the CTRIO.
Rung 2 lets you set the amount of time you must be stable before considering the move complete. Obviously that is a tradeoff between speed and stability.
Set the target, run the program, and wait until the program block's .Done bit turns on.
It will definitely reverse as much as is required to make Error go to 0, and as I mentioned, will oscillate if you get the gain too high.
-
I mistook the MIN function. I see it sets a max.
I have a question about edge triggered contacts. If a multiscan output is edge triggered will it have power flow as long as its rung is being scanned or does it need a constant power flow contact? I have used an edge trigger to limit it to one time process.
I'm trying to avoid a condition of premature power loss to multiscanned instructions.
I've decided not to put multiscanned instructions in a TASK. If a timer is involved I'll put it in the PROGRAM that enables the task until I can get a better understanding. I'm confused on this area of instruction functionality .
Actually what I need is a detailed description of what can go in edge triggered tasks and expect to complete before the task ends and what cannot. Is there a HELP document on this?
-
A multi-scan edge triggered instruction should NOT be triggered by an edge contact (otherwise it will only be powered for one scan). It will not be re-triggered unless the contact turns off and back on.
A task is only intended to be used for a one-shot (usually one scan) process. Once a task reaches the end of its ladder it is done; so the only way to make it multi scan is to 1.)make the ladder long enough to exceed the tasks timeslice, 2.)use a YIELD instruction, 3.) use a looping instruction that will cause the scan to jump back and re-scan a portion of code. Tasks are very handy and I use quite a few of them (with a lot of loops too), but most of the time you will be using Program blocks instead.
Hopefully I didn't muddy the water too bad. ;)
-
Not muddy, a bit clearer now. I'm trying to make myself a rule to keep out of trouble.
So I must think "Keep power on until instructions can complete".
So if I put a timer in a task it needs to loop until Timer.Done? So how is the TASK ended with a loop in it?
I have one TASK and several PROGRAM blocks, so far. I'm trying to segregate instructions so it's easier to manage and read, hence more TASKS.
-
A multi-scan edge triggered instruction should NOT be triggered by an edge contact (otherwise it will only be powered for one scan). It will not be re-triggered unless the contact turns off and back on.
Are you sure about that? If it's edge triggered, I'd think its enable state should latch, elsewise what's the point of it being "edge-triggered" vs level triggered?
-
Edge triggered instructions latch the request and run until complete without regard to the input state. They will not begin evaluating the input again until after completion, and will require a rising edge on the input to run again. Using an edge contact on an edge triggered instruction isn't harmful, but neither is it helpful.
A multi-scan instruction does not need to be constantly driven, unless the input is used as both a trigger and an enable, like in the case of some of the CTRIO instructions. The rising edge triggered the profile load, after which the input becomes the output enable.
A multi-scan instruction does need to continue running until completion. If you put the multi-scan instruction in a stage, task, or program that gets disabled before it completes, it will not work correctly. That's why we recommend that you put them into stages and use the built-in stage transition mechanism.
Tasks are generally not the correct place for timed events, use a program instead. Tasks are great for concurrent logic that is enabled by a controlling program, once or recurrently.
A single execution of a task is running from the top to the bottom...when it hits the bottom it is deemed to have completed. If it is enabled to run continuously, it will restart after the specified interval. If the task contains some looping construct, it will take as many scans as required to complete the loop, and then will eventually hit the bottom. That might be one scan, or never if your loop never terminates, but I would consider a non-terminating loop to be broken code.
Programs run continuously until EXIT is called. The motor control I posted was a program block, and I used the timer .Done to trigger the EXIT.
-
A multi-scan edge triggered instruction should NOT be triggered by an edge contact (otherwise it will only be powered for one scan). It will not be re-triggered unless the contact turns off and back on.
That's not really true. A single edge will trigger the instruction, regardless of whether it is continually driven after the fact. The key thing is that the code block containing the multi-scan instruction must continue to run until completion. If you kill the program or stage it is in, we'll forcibly terminate the instruction and post a system warning, but the input state has no bearing on that.
-
A multi-scan edge triggered instruction should NOT be triggered by an edge contact (otherwise it will only be powered for one scan). It will not be re-triggered unless the contact turns off and back on.
That's not really true. A single edge will trigger the instruction, regardless of whether it is continually driven after the fact. The key thing is that the code block containing the multi-scan instruction must continue to run until completion. If you kill the program or stage it is in, we'll forcibly terminate the instruction and post a system warning, but the input state has no bearing on that.
OK, I didn't realize that, Thank you for the correction ;D
-
This discussion has helped and I answered my own question by going to my notes. Programs and Tasks Overview DMD0231 makes more sense now as I know much more than I did the first time I read it.
I will a TASK to set parameters from operator input. It takes several rungs and all done in one pass. It cleans up my PROGRAM and once working I don't need to scroll through it again when editing my instructions.
This is my first PLC experience and I can't imagine not having PROGRAMS, TASKS and STAGES. Thank you HOST!
My troubleshooting has been productive, easy and I learn from my mistakes. It gets easier every day. Thank you HOST!
Support for Do-more has exceeded any experience for any computer based product I have ever used. Thank you HOST! and users on this forum.
-
Very glad to hear that it's working well, and thank for the kind words on Do-more!
-
Today I started troubleshooting Bernie's control. I need to know what the source is for PositionIn. I have encoder on input 1 so is it $CTRIO_000_C1F1.iReg1 like I've been using?
If that's correct then I would substitute $CTRIO_000_C1F1.iReg1 for PositionIn.
-
PositionIn is a D location, and could be substituted for the encoder value directly or keep the D as an intermediate value and copy to it from the encoder. I like the latter personally, because I like keeping a layer between the program and the actual I/O.