Internet PLC Forum

I think I know what the problem with the program. The TBASIC parser does not handle the "n" part of the goto @n correctly.

The online documentation for GOTO:

To branch unconditionally out of the normal program sequence to a specified line with label @n within the present Custom Function. The destination line must have a corresponding line label marked as "@n", where n must be a constant within 0-255. Note that the label is local only to the present CusFn. i.e. another CusFn may have a label with the same n but the GOTO @n will only branch to the line label within the same CusFn.


Is not correct. The range 0-255 is that of an unsigned 8-bit integer.  The TBASIC parser accepts "n" in the rage of 0-255 decimal as well as &h00 to &Hff as an 8-bit value but subsequently sign-extends it to a 16 or 32-bit variable.  

The error message gives it away.  The "-36" as an 8-bit signed value is 0xDC. If 0xdc is treated as an unsigned 8-bit variable then it would be 220 decimal.  The code has "@220" as a target of a goto but the parser can't find the target if it is between 128 and 255.
 
You might consider correcting the documentation for goto @n to indicate that the only usable values for n are in the range of 0..127.

One more small niggle.  The syntax highlighter makes the “@“ turn color only when it is in the first character on a line.  If the line number is anywhere else the "@“ highlighted.  

The TBASIC parser does work correctly and has no issues with where the @xxx line numbers are placed.  The code compiles and runs correctly.

Best regards,

Gary D*ckinson

Thanks for the info on the delay statement.  

So far I have found that the WDT is reset during the execution of:

  for/next
  while/endwhile
  delay statements

I can get the WDT to reset the PLC with during the excution of the following CF:


' TimeWaster this code is supposed to start the WDT and then force the
'   WDT to reset the PLC before the CF completes
'

setsystem 255,&hb3      ' EnableWDT 2.67s timeout with Nano-10 R82A firmware

setsystem 255,&h00      ' reset WDT


' Ok try and break the WDT using a while/endwhile based using goto statements
'
i = 300                     ' 300 loops of 10 ms is about 3 seconds
@100
if (i = 0)                  ' while(i)
   goto @110
endif   
   RSHIFT DM[32],256         '    this kills 2.0 ms on a Nano-10
   RSHIFT DM[32],256         '    this kills 2.0 ms on a Nano-10
   RSHIFT DM[32],256         '    this kills 2.0 ms on a Nano-10
   RSHIFT DM[32],256         '    this kills 2.0 ms on a Nano-10
   RSHIFT DM[32],256         '    this kills 2.0 ms on a Nano-10
   i = i - 1
goto @100                  ' endwhile

@110
a = 100                     ' loop exit marker


I have, also found that the WDT mechanism is only active during the execution of CF functions. If I enable the WDT and no CFs are invoked from the ladder logic, the WDT does not reset the PLC.

The documentation describes the Watch dog Timer with "If enabled and the CPU goes astray because of noise-induced trouble, the WDT will reset the CPU when it times out. Note that to simplify user's application the TBASIC O/S automatically resets the WDT during its normal execution except when the program is stucked".

Does this mean that if the CPU goes astray and the the ladder logic scanner quits running that the WDT can not reset the PLC?

I am trying to figure out a mechanism to reboot the PLC when it has gone astray.  The WDT doesn't do this. It seems to be enabled during CF execution and not ladder logic execution.

Additionally if the WDT does timeout in a CF it breaks the connection with the on-line monitoring.  I find that I have to disconnect from the PLC and re-connect to the PLC to get on-line monitoring working.

Sorry to be such a pain.  But I am guessing that no one has ever attempted to use the WDT mechanism.

Best regards,

Gary D*ckinson

I have a client that is concerned that his PLC based system is becoming non-responsive.  He has 25 of these systems running in at least 3 different countries. These systems have been running for 3+ years.

I am looking at the SetSystem 255 command.  This is described as an "on-CPU Watch Dog Timer".  I fully understand the concept of this mechanism.

However I am puzzled by the documentation.  The initial description, "If enabled and the CPU goes astray because of noise induced troube, the WDT will reset the CPU when it times out."  This is exactly what I would expect for a WDT.

Here is where I get into trouble.  The documentation talks about "when the programed is stucked [sic] inside a GOTO loop".  Then the documentation states that "the WDT will not kick in if your program is stucked [sic] inside a FOR..NEXT or WHILE..ENDWHILE loop."  So you are telling me that the WDT only works in a GOTO loop but not FOR..NEXT or WHILE..ENDWHILE?  This makes no sense.

Now for the big issue the documentation states, "WDT also will not activate if your program encounters undefined interrupt error..."  

I believe that there is a SetSystem command that allows me to set up an trap for undefined interrupts.  I, currently, can't find where this is documented, but I believe that I can create a CF that could reset the PLC in the event of these interrupts.

Can I use both the WDT and the undefined interrupt trap at the same time?

Can you point me to the documentation for the interrupt trap?

Best regards,

Gary D*ckinson

I can address your observation that the decimal value 95674 (HMI) ends up wrong in the PLC DM memory.

This is a word order issue.  The data transfer protocols that the HMI/PLC use break up 32-bit values into two 16-bit words.  The 16-bit values are sent and then must be reassembled on the receiving end. The problem is that the PLC and the HMI do not represent 32-bit values the same way.

The 32-bit decimal value of 95674 is 0x000175BA in hex.  The most significant 16-bits of the value is 0x0001 (1 decimal) and the least significant 16-bits is 0x75ba (30138).  If you use the i-TRiLOGI simulator you can write 95674 to DM32[1] and then View the DM memory as 16-bit data and you will see that DM[1] holds the value 1 and DM[2] holds the value 30138.  On the PLC the most significant part of a 32-bit number is stored first in PLC 16-bit memory (big endian).

In your example you started with the value of 95674 on the HMI and when it got sent to the PLC the 16-bit (word) order got messed up.  The HMI stores 32-bit values with the most least significant word first and the most significant word in the next memory location (little endian).

The HMI is sending the 32-bit data in the wrong order for the PLC.  If this is what you are seeing then you need to coerce the HMI into sending the 32-bit data in the correct order for the PLC to reassemble correctly.

You did not specify what protocol that you are using for the HMI to communicate with the PLC.  I would suggest that you use Modbus.  I can help you with the Modbus protocols.

Specify the data transfer protocol used by the HMI to communicate with the PLC.  I use Modbus RTU via the RS-232 port.  The critical part is "Conversion...".  Click on this button near the bottom right corner.  You want to set the 3x_Double and 4x_Double conversion to use the "ABCD -> CDAB" data conversion.  What this does is change the order that the 16-bit data words are sent/received to ensure that  the 32-bit value makes sense to both the HMI and PLC.

Now, set up address tag to access DM32[1] as a 32-bit signed integer:

• Create an address tag and give it a name that makes sense
• PLC: "MODBUS RTU"
• Address type: 3x_Double   (this gets the word order correct)
• Address: 1001 (this is the correct Modbus address to access DM32[1]. Address 1003 is used for DM32[2])
• Data format: 32-bit Signed
• Conversion/Calculation  (leave the Enable box unchecked)

If you are attempting to use the Host Command protocol, then you will need to call TRI for assistance.

Best regards,

Gary D*ckinson

Lorne,

I will try and explain how TBASIC works with data that is either stored in 8,16 or 32 bit variables or started out life as a 8,16 or 32 bit variable.

I will not discuss floating point stuff, but bear in mind that certain PLCs work with 32-bit floating point values.

Rule #1 TBASIC, internally, only deals with 32-bit signed integers.  

But, the PLC allows you to store and retrieve integers from 8,16 and 32 bit storage.  DM allows 16 and 32 bit access.  EEPROM can be accessed as 8,16 and 32 bit integers.  Some TBASIC functions return 8 or 16 bit values, and you may get surprised when your code does not function as you had hoped.

Signed Integer Rages for 8,16 and 32 bit variables:

Size in Bits	Max Decimal	Max Hex	Min Decimal	Min Hex
8	127	7F	-128	80
16	32,767	7FFF	-32,768	8000
32	2,147,483,647	7FFFFFFF	-2,147,483,648	80000000

Rule #2 How are things stored in 8/16/32 bit variables.  If the variable is "too big" to fit in a given size variable, then only the least significant bits can be used.  As an example, if you try and store a value of 18,264 (&h4758) in an 8-bit variable only the least significant 8-bits will be used.  The 8-bit variable will now be 88 (&h58).  You may lose some precision.

Rule #2 is a bit like me with shoes.  I wear a size 14, to fit into a size 8 I will need to lop off my toes.

Back to Rule #1: TBASIC only actually works with 32-bit signed variables. If your TBASIC code uses 8 or 16 bit data sources, the 8 or 16 bit values will be "signed extended" to a 32-bit signed integer before it will be used.

Why is this important?  If you read an 8-bit value from a serial port using the INCOMM(n) command and the 8 bit value read from the communication port is &hA3 (-93 decimal)

    A = INCOMM(3)
[/font][/color]
The value assigned to the variable, A, will be &hFFFFFFA3 (-93 decimal).  This is an example of sign extension.

The following code will fail:

    A = INCOMM(3)
    If (A = &hA3)
        ' do something if the character was &hA3
        '
    endif
[/font][/color]
Why will it fail?  The variable A will hold &hFFFFFFA3 and it is being compared against &h000000A3.  The hexadecimal constant, &HA3, is treated by TBASIC as being a 32-bit value and TBASIC just compares one 32-bit thing against another.

Lorne.  This is just the way that TBASIC works.  It's not wrong, but it is not clearly documented by TRI.

If you can use DM32[] for storing integer data, then only use DM32[] method.  Now anything in A..Z and DM32[] will be 32-bit and TBASIC will not need to sign-extend or truncate data.  Same goes with integers stored in EEPROM, use the 32-bit access methods.

Oh, and your comment about "-1234 or FFFFFB2E are 32 bit values" is not exactly true.  -1234 can be accurately represented by both 16 and 32-bit signed variables.

Best regards,

Gary D*ckinson

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

Neal,

You have made good progress.  Test the mess out of your prototype system. The 2nd limit switch may help detect door open/close issues.

As Lorne has indicated, steppers may not be the best solution for your door actuator.  I think of your application as being similar to “power windows” in automobiles. Automotive window lift mechanisms have the following characteristics:
1. High torgue geared DC motors. Tremendous starting torque. And the gear train (often worm gear based) holds the windows in position when the motors are not powered.
2. They sense motor current to detect when the window hits either the full open of full closed stop position. They actually use a quadrature encoder on the motor shaft.  They use the encoder to calculate the velocity of the window motion. When the velocity hits zero the window quit moving. This is how they detect the up and down limit position.
3. The current sensing The encoder, also, allows them to detect windows that are blocked from motion by by either a mechanical failure or a human body part window is moving slower than normal. In either case the window control mechanism attempts to reverse course.
4. If the window controller supports an “auto up/down” operation, the mechanism includes some sort of encoder that keeps track of motor rotations so that the window, once calibrated, can be moved based on position feedback rather than depending on the motor current to spike when they hit the full up/down position.

My current crop of Honda cars have window actuators with theses behaviors and they need to be re-calibrated if actuator is replaced or the battery has been disconnected. The calibration procedure is pretty simple, lower the window and then raise it and keep holding the “up” button for a couple seconds after the window gets to full the full up position.

This a link to a low cost geared-DC motor with a quadrature encoder:

https://www.servocity.com/26-rpm-premium-planetary-gear-motor-w-encoder

The PLC supports quadrature encoders. You can use two single pole double throw relays to get motor up, motor down, and motor braking.  Same number of I/O's that you needed for a stepper and 2 limit switches. And you get better feedback on where the door is positioned and if their is a problem the  prevents the door from moving properly.

Good luck with your project,

Gary D*ckinson