Having a problem with CTAXCFG

[ERokc]

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!

[BobO]

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.

[ERokc]

Exactly,  CTREGWR was never going to do it no matter how many times.
Works now with $FirstScan enabling CTAXCFG once.
Thanks!

[BobO]

CTREGWR should actually work fine. If it isn't, I need to know about it.

[ERokc]

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!

[BobO]

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.

[ERokc]

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.

[BobO]

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.

[ERokc]

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?