Having a problem with CTAXCFG

[ERokc]

I have been running a position with CTAXCFG and CTAXDYNP and it's working.
I want to offset the count so in CTAXCFG I change Init Out Pos from zero to a variable and even tried a constant.  It accepts my values (green dot) but ignores the count.  I set Current Pos to Maintain in CTAXDYNP.  It runs the same no matter the Init value.

What am I missing?

[BobO]

Check the box to enable updating the output position.

[ERokc]

Can't find the box?

[BobO]

On CTAXCFG box, there is a check box beside the output position field that forces the instruction to update axis' internal position. If it isn't checked, the position is unchanged.

[ERokc]

That box is enabled.  It won't take a value if not enabled.

Not working!

[BobO]

And you are toggling the box's input to re-run it? That's puzzling. I'll look into it.

[ERokc]

When I'm having problems I go into program mode, Write PLC if needed and back to RUN.

On success it goes to the next stage containing CTAXDNYP.

For debugging purposes I monitor the counter registers and there is no update for the Init value I entered.  The move runs to the same point no matter what I put there.

I've looked for a way to write to OutputPosition but it appears to be Read only.

Is OutputPosition scaled by the scale set in the configuration for the encoder?

[BobO]

Not at work to check the code, but it obviously isn't pushing the value back to the input channel. Easy workaround is to use the CTREGWR function to update the value.

[ERokc]

I knew about and forgot CTREGWR.  My wife has reminded me it's time to cut the grass.  I'll try running it later.
Thanks

[BobO]

Found the problem. Minor bug. Looks like it would work if the output was already in axis mode...like if you called CTAXCFG a second time...but will fail the first call. Easy fix to the CTRIO2 firmware.

[ERokc]

Yeah! wasn't me this time.  CTREGWR to position worked so I'm onto the next part which is preset tables and DRUM.

I will stick with my current plan at this point because I understand it and I need to keep moving.  What I like about software is changing it is just keystrokes.  No cutting and cleaning up welds, no machining new parts, no mess to clean up, well sometimes there is a mess.

If I want to change later I can and what attracts me about Do-more among many other things is the ability to communicate with the PLC over the internet. It's going to save me a bunch of miles.

Thanks for your help

[BobO]

Oh, there's plenty of bugs left for you guys to find...just ask plcnut...he's found more than his share. Just glad there is an easy work around to keep you going. If it is holding you up, I can get patched CTRIO2 firmware pretty quickly. Just let me know.

[ERokc]

Easy workaround. Save it for the next release. I always try to figure out what the problem is first then ask if I can't get it.  I learn a lot in the process.

I don't fully understand the VFD motor control you offered.  I need to keep moving to get the machine commissioned but plan to go back and study it. I know I will learn something and probably be very useful.

[ERokc]

A related problem is CTREGWR does not write the first time after PLC RUN.
I put it in $FirstScan to kick it but it doesn't work there.  Is that because it's one scan and cannot complete?  If so that's telling me that even though it's asynchronous and edge triggered it needs power until success.  Is that correct?

So I put it in my HOMEing function which is required on power up and nothing else will be running at that time.

New problem (maybe question) about CTAXDYNP, I'll make a new post.

[BobO]

A related problem is CTREGWR does not write the first time after PLC RUN.
I put it in $FirstScan to kick it but it doesn't work there.  Is that because it's one scan and cannot complete?  If so that's telling me that even though it's asynchronous and edge triggered it needs power until success.  Is that correct?

So I put it in my HOMEing function which is required on power up and nothing else will be running at that time.

New problem (maybe question) about CTAXDYNP, I'll make a new post.

$tFirstScan executes once and cannot work with async instructions, and you should be getting a warning from the program check. You can use $tFirstScan to start a program block that will do it, or you could use $FirstScan (the bit, bit the task) to do it.