CTRIO2 _Out0.OutputVelocity polarity?

[ERokc]

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.

[franji1]

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.

[BobO]

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.

[ERokc]

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?

[BobO]

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.

[ERokc]

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

[BobO]

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.

[ERokc]

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?

[plcnut]

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.

[ERokc]

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.

[Controls Guy]

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?

[BobO]

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.

[BobO]

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.

[plcnut]

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

[ERokc]

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.