Host Engineering Forum
General Category => CTRIO and CTRIO2 => Topic started by: ERokc on August 01, 2013, 02:12:39 PM
-
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?
-
Check the box to enable updating the output position.
-
Can't find the box?
-
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.
-
That box is enabled. It won't take a value if not enabled.
Not working!
-
And you are toggling the box's input to re-run it? That's puzzling. I'll look into it.
-
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?
-
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.
-
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
-
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.
-
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
-
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.
-
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.
-
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.
-
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.
-
I had the workaround functioning. It quit and I can't figure it out now. It's really frustrating when you fix it then break it and can't fix it again.
Without spending time on it would you see what might be run to get past the first reg write prob. I have been writing with CTREGWR and even CTAXCFG at the beginning of the program run. It's just not tripping whatever is hanging the first write. Something in the module might need to run after the first write, just guessing!
-
Only the first call to CTAXCFG will fail to init the position. Every subsequent call should be fine, as long as you don't leave axis mode. Using any profile instruction that doesn't begin with CTAX will take it out of profile mode. It may even be fine leaving axis mode, but I need to confirm that by checking the code.
-
Exactly, CTREGWR was never going to do it no matter how many times.
Works now with $FirstScan enabling CTAXCFG once.
Thanks!
-
CTREGWR should actually work fine. If it isn't, I need to know about it.
-
I used CTREGWR to init the position because CTAXCFG would not on the first run.
CTREGWR did not write either so thinking it needed a "pre write" to get past the prolem I put one in using a $FirstScan contact. Didn't work but in the process I had something working then broke it. I must have used CTAXCFG at one time in the "Pre write" then changed it.
Anyway I have to use CTAXCFG triggered by $FirstScan then the first motion move runs correctly.
CTREGWR may be writing but does not fix the first write of CTAXCFG. You said it has to be in the axis mode. Does CTREGWR put in axis? I don't see "AX" in its name!
-
CTREGWR is a general purpose method of setting internal function registers in the CTRIO. Pretty sure it works just fine.
CTAXCFG is the axis mode configuration function. It is the only way to get to axis mode. Is provides an option to set the axis position, which is simply setting the outputs internal output position register or the associated encoder's position register if configured for closed loop.
The bug is simply that the position register was being set prior to setting closed loop mode, hence, it thought it wasn't in closed loop mode and set the output register, rather than the encoder position. When you call it a second time it is already in closed loop mode and sets the encoder.
CTREGWR is actually aware of the output being in axis mode and sets the correct register when you write to the output position. If you were to write to the encoder position, it will set it regardless of the output mode...but the encoder input won't become the output position until the axis is in closed loop mode.
It all sounds pretty complicated, but it really isn't. There is one minor bug that prevents the CTAXCFG from correctly updating the encoder's position on the first call. That can be corrected by a second call to CTAXCFG, or by writing to the encoder's input position via CTREGWR...but...you must call CTAXCFG at least once to put the output in axis mode.
-
I have the first time CTREGWR write problem handled so I'm on to tables.
I mentioned before that I intend to use DRUM to select devices to operate at each discrete table count. Your comment about DRUM was it's made for another use. You're right, it is an overkill and not necessary. The PLC I used in school did not have near the functionality of Do-more and DRUM was simpler and a visual way to enter the points. Never did really write any instructions as Do-more was released in the middle of the semester. It immediately caught me attention. My thoughts were "this is what a PLC should be, not the primitive control I was being taught". Thanks to all at host for creating an up to date product.
That said I'm setting up a one dimension table. I will create the pattern in binary (time consuming part) in Excel and enter ALL the values in Hex into the table. I learned about casting so I can select the bit for each device to fire. It would be nice to import data into Do-more.
-
Your comment about DRUM was it's made for another use.
I don't remember saying anything about DRUM, only preset tables and pulse outputs. There is no right or wrong way top use any of it. If it works, use it. The only reason I have been discouraging you from using some of the CTRIO stuff is simply because you are using it for things it wasn't designed...hence...it may not work. Given that you are relatively new to PLC programming, I'm just trying to keep you from painting yourself in a corner.
No, ask anyone who knows me...I love using things outside their intended purpose...it's the MacGyver gene in all engineers. I just don't recommend that for newbies.
-
I understand exactly what you mean and I appreciate your guidance. It could have been someone else suggesting to not use DRUM. I'm with you, if it works that's what counts. However trying to make something work when there is a better way I'm for the better way!
I created a User Memory Block. What I need is a ROM table as the program does not need to change the values but RAM is OK if that's what's available.
So my question is how do I get the data into the table "Memory Block"? Do I need a different structure?