CTRIO2 _Out0.OutputVelocity polarity?

[ERokc]

Does it go negative when CTRIO reverses?

[plcnut]

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.

[ERokc]

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.

[BobO]

There is a direction flag. It is very simple to create a negative velocity.

[ERokc]

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.

[BobO]

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.

[BobO]

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.

[ERokc]

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?

[BobO]

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.

[Gene Bond]

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!

[BobO]

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.

[Controls Guy]

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.

[ERokc]

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.

[ERokc]

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.

[ERokc]

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!