Stepcount() and stepcountabs()

[nealbert]

How do I use the functions STEPCOUNT(X) and STEPCOUNT(X) in a CF?  The documentation only says this function returns the relative (or absolute) number of step moves.

There are no examples in the documentation, so I assumed I just need a simple equality in oder to use the value that STEPCOUNT returns.  Something like....

DM[1] = STEPCOUNT(1)   or    A = STEPCOUNTABS(1)

Is this correct so far?

If it is, then why do I get Error : unknown keyword:"stepcount"  (or "stepcountabs") every time I run Simulation or try to download my program?

Also, is the number that is returned 16 or 32 bit?

Thanks in advance,
Neal Cooper

[garysdickinson]

Neal,

The function, StepCountAbs(ch):

• Returns the current absolute position of the stepper system as a 32-bit signed integer
• The argument to the function, ch, is the stepper channel number, typically, 1..8.
• The absolute position for a stepper channel is reset to a value of 0 when the PLC is reset.
• The absolute position for a stepper channel is set to a value of 0 when the "StepHome ch" statement is executed.
• If you issue a StepMoveAbs or a StepMove that results in the stepper system moving, then this will affect the current absolute stepper position.
• If you call the StepCountAbs(ch) function while the stepper system is moving, you may get an intermediate value returned.

The function, StepCount(ch):

• Returns the current relative position of the stepper system as a 32-bit signed integer.  
• The relative position is the number of steps that the system has moved since either the last motion command was executed or the PLC was reset the SetHome statement was executed.
• The argument to the function, ch, is the stepper channel number, typically, 1..8.
• The relative position for a stepper channel is set to a value of 0 when the PLC is reset.
• The relative position for a stepper channel is reset to a value of 0 when the "StepHome ch" statement is executed.
• If you issue a StepMoveAbs or a StepMove that results in the stepper system moving, then this will affect the current relative stepper position.
• If you call the StepCount(ch) function while the stepper system is moving, you may get an intermediate value returned.

OK what is the use of these commands?  If you use the StepStop statement to abort a motion command, then the StepCount and StepCountAbs would allow you to determine the position of the system.

OK for your questions:
Q: Is this correct so far?  
A: Yes. But, "DM[1] = STEPCOUNT(1)" is not an "equality" it is an "assignment" statement.  Yes, I am being a bit anal, but you asked...
Q: Also, is the number that is returned 16 or 32 bit?
A: It is a 32-bit signed value.  

I would suggest that you use DM32[] rather than DM[].  You have to be very careful with DM[] because it is a 16-bit signed value.  TBASIC does all of its operations as 32-bits. 16-bit things are sign-extened (promoted) to 32-bit values before they are used in expressions. Assignments from TBASIC to 16 bit things will be truncated to 16-bits.

Truncating a 32-bit signed integer to 16 bits may result in both loss of magnitude and sign (positive or negativeness) . The 16-bit result may not be very useful...

Sign extending from 16 bit to 32-bit will result in the extra 16-bits being set to 0 or 1 values based on the 16-bit value's most significant bit. Nothing gets lost in this direction, but you can write TBASIC code that fails because you forgot about this 16/32 bit behavior.

This 16/32 bit stuff is just a statement of life with integer arithmetic.  Be VERY careful with this. It WILL bite you in the butt if you are not careful.  You have been warned.

Q: If it is, then why do I get Error : unknown keyword:"stepcount"   (or "stepcountabs") every time I run Simulation or try to download my program?
A: I can't answer that because you didn't post your code.  But my guess is that you screwed up the syntax.   The following code runs fine in simulation:

Code: [Select]

DM32[1] = StepCount(1)
DM32[2] = StepCountAbs(1)

You are free to look at my posted code on how I use the stepper controller:

http://www.triplc.com/yabbse/index.php?board=1;action=display;threadid=2347

Best regards,
Gary D*ckinson

[nealbert]

Gary,

Thanks again for the feedback.  You obviously did not get this wealth of information from reading the Trilogi online documentation.  I'm glad you know this stuff.  You should write a book  ;-)

I have been bitten by the 16/32 bit stuff.  And yes, it is hard to debug.  That's why  I wanted to make sure what size word it is before I shoot myself in the foot, again.

Strangely, today I do not get the "unknown keyword" error when I put the statement "DM[1] = stepcount(1)" in my CF.  I'm positive I was typing it correctly the other day,  so who knows.

On a related topic, I was trying to download software in to a clients PLC in Los Angeles today (I'm in Dallas, TX) and I got the "unknown keyword" error on a relay name that has been in my code almost since day one.  The exact same version of software download to the PLC in my shop yesterday with no problems.  But today, 600 miles away..."Unknown keyword".  I'm going to send them a newly saved file and just chalk this up to sun spots or ebola or that wild & crazy Vlad Putin hacking my computer.  Unless, of course, you have a any suggestions.

Thanks,
Neal Cooper

[garysdickinson]

Neal,

I just mess with the PLCs to ward off Alzheimer’s. I have messed with the TRI PLCs for the last 15 years and have broken their firmware often. I have almost figured out how the PLCs actually work.

I have a couple of thoughts on your “unknown keyword” issues:

• TRI has actually added new keywords to the i-TRiLOGI tools. If your distant client is having problems with code that compliles for you, then there is a possibility that your distant client is using a real old version of i-TRiLOGI.
• The i-TRiLOGI compiler uses an expression parser that is based on a recursive descent algorithm. The classic behavior of this sort of software mechanism is that by the time the parser figures out that your program is non-sense, the parser is many lines beyond the actual problem.
• So if you are getting error messages, then the actual problem is almost never on the line of code that the compiler is complaining about. Back up 1 or 2 lines in your program and try and figure out what went wrong.
• I have been able to write code so crappy, that the offending bit of code was in the CF that preceded the CF that got a complaint from the compiler.
• If you can’t see the problem then I’d comment out the entire CF using /* and */ and see if this make the error go away.  Now move the /* and */ around until you isolate the offending program bit.

I’d be willing to have a look at your code and see if I can find the bit of code that annoys i-TRiLOGI.  You can send it to the email address in my profile:

 gary.s.d*ckinson@me.com.

(Substitute an “i” for the “*”, the Forum considers my family name obscene and changes it to something that it considers PG).

P.S. There is one more think to worry about when you are working with i-TRiLOGI and are getting strange results.  Reboot your computer.  i-TRiLOGI and JAVA are not always on speaking terms and I have been half way into writing hate mail to TRI before figuring out that a reboot is needed to get stuff working.

Gary D*ickinson

[nealbert]

Gary,

Thanks again for the great feedback.   We took the easy way out this time and just overnight an FMD88-10 to my client that had working code in it.  That'll get my a$$ out of the fire for now.

I think you hit the nail on the head about the software version  I installed the version on their laptop when I was out there a couple of months ago.  I used the Trilogi Started Kit DVD so it's an older version than what I'm using here in my office.  Oops.

Guess It's time I learned how to log into a remote FMD88-10 to upgrade software.  Always something new to learn.

Regards,
Neal Cooper

[garysdickinson]

Good luck with your remote customer.  

One of my clients adds a 4GLTE MODEM to his PLC based system.  The systems are mounted on trucks and are always on the move.  He had a issue with one of these systems and I was able to remotely connect to the system and with on line monitoring figure out what was happening.

I have used TeamBuilder to connect to another client's PC and debug and load new code.  This approach got around the issue that the PLC was on a local network and not visible from the internet.  This client is not a computer guy and was not able to set up his DSL router to allow access to the PLC.

TeamBuilder made it pretty simple.

Gary D