Internet PLC Forum

I think that i-TRiLOGI is trying to give you a hint.  Sort of like the old joke, "Death, is nature's way to telling you to slow down".

There are real world limits on how complex a line of ladder logic you can construct.  You have exceeded what the ladder logic editor can handle.  You are lucky that you have gotten a hint.  I'd suggest that you simplify your ladder logic and break up the logic into simpler bits.

In regards to the flashing in simulation/on-line monitoring...  The simulator is attempting to highlight the contacts that are active.  If your logic is changing rapidly the simulator will be very busy rewriting the screen.

I have run the PLC tools on many different computers and would not describe the behavior as a strobe effect on any of them.  Most of my computers were picked to support 3d CAD CAM programs and Photoshop so the graphics hardware may be a bit more powerful than that in your laptop.  I assume that you are using the most up-to-date drivers for your video hardware, the most up-to-date version of Java and the latest version of i-TRiLOGI.

Good Luck,

Gary D*ckinson

Lorne - I've attached a PLC program to this message that demonstrates a simple FIFO mechanism for storing string messages in non-volatile memory.

I would suggest that you play with this program using the i-TRiLOGI simulator until you can understand how it works.

I use the #Define mechanism exhaustively to create readable names for variables.  So the first thing that you need to do is open one of the custom functions and open the #Define table.

#   #Define Name   Value
1   ENQ_Offset      DM[1]
2   DEQ_Offset      DM[2]
3   FIFO_Cnt         DM[3]
4   FIFO_Size         5
5   FIFO_StartAddr   1

You will note that use 3, 16-bit integer variables to manage the FIFO. ENQ_Offset is used when a message is added, enqueued, to determine where in non-volatile memory to write the data.
DEQ_Offset is used when a message is removed, dequeued, to determine where in non-volatile memory to retrieve the data.
FIFO_Cnt is the current number of message stored in the FIFO

The FIFO_Size define determines the FIFO size in the count of messages.  For my test code, it is 5.  Adjust as needed
FIFO_StartAddr is the starting address in non-volatile memory. For my test code the starting address is 1.  Adjust as needed.

There are 2 RELAYs that you can use in both ladder logic and in custom functions to determine the current FIFO status:

[*]MsgFifoEmpty - set when FIFO is empty and holds no messages
[*]MsgFifoFull - set when the FIFO is full and if a new message is equeued then the oldest message in the FIFO will be lost
[/list]
This is the entire custom function to enqueue a string in the FIFO:
' EnqueueMsg - function to enqueue an array of 40 character messages into the Message FIFO
'
'
' On entry A$ holds the string to enqueue
'  This FIFO uses the SAVE_EEP$ statement to store data in the non-volatile memory.
'  The message length is limited to 40 characters
'
'  On exit: The A$ will be written to the FIFO  
'         The FIFO_FULL and FIFO_EMPTY RELAYS may be affected.
'         The DM[] variables ENQ_Offset, DEQ_Offset and FIFO_CNT may be updated.
'         If the FIFO is full then the B$ variable will be written with
'             the oldest message in the FIFO to make room for the new message


'  If the FIFO is FULL, then discard oldest message in the FIFO
'
IF TestIO(MsgFifoFull)
   ' the FIFO is full, but Lorne is OK with overwriting old messages
   '  so we will discard the oldest to make room for the newest message.
   '  This action overwrite the value of B$
   '
   Call DequeueMsg
ENDIF

SAVE_EEP$ A$,FIFO_StartAddr + ENQ_Offset   ' write one entry into the FIFO      

' Update FIFO index, counter and flags
'
ENQ_Offset = (ENQ_Offset + 1) MOD FIFO_Size
FIFO_Cnt = FIFO_Cnt + 1

IF FIFO_Cnt = FIFO_Size
   SetIO MsgFifoFull         ' the FIFO is full and cannot accept more data
ENDIF

ClrIO MsgFifoEmpty            ' FIFO cannot be empty

This is the entire custom function to enqueue a string in the FIFO:
' DequeueMsg - function to dequeue String data from the String FIFO
'
'  On exit:
'          B$ will hold the oldest string in the FIFO.
'         The FIFO_FULL and FIFO_EMPTY RELAYS may be affected.
'         The DM[] variables ENQ_Offset, DEQ_Offset and FIFO_CNT may be updated.


'  Return message from FIFO in B$
'
IF TestIO(MsgFifoEmpty)
   ' the FIFO is empty and there were no values to remove from the FIFO
   ' Just return a NULL String
   '
   B$ = ""
ELSE
   ' the FIFO was not empty, so return oldest message in B$]
   '
   B$ = LOAD_EEP$(FIFO_StartAddr + DEQ_Offset)

   ' Update index, FIFO count and flags
   '
   DEQ_Offset = (DEQ_Offset + 1) MOD FIFO_Size
   FIFO_Cnt = FIFO_Cnt - 1

   IF FIFO_Cnt = 0
      SetIO MsgFifoEmpty   ' the FIFO is empty and there is no more data to remove
   ENDIF

   ClrIO MsgFifoFull         ' FIFO cannot be full

ENDIF

This approach may seem like lot of work, but it actually takes very few lines of code and executes very rapidly.  This is classic computer science done without the help of modern computer languages.

Best regards,

Gary D*ckinson

9080 sounds like the port number used in the IP address of the PLC.  This may be from some experiment that you are using with the GET_IPAddr statement that will build an array in DM that represents the IP address including the port number of 9080 in 5 ascending DM[] registers.

Gary D*ckinson

Excellent on 10/12 bit behavior on older PLCS.  

I used an external 16-bit  ADC on my T100MD projects after testing the PLC's DAC cabibilities and determining that 10-bits was not quite enough. I'd forgotten that fact.

The analog ground and 5V reference wiring has a high probablity of giving you odd ADC values.

Good hunting,

Gary D

Thanks.  I like algorithm questions.

I was surprised that my sample code for jbryant87 resulted in unintentional Unicode characters.  So I offered him a second version that forced the argument, n, in CHR$(n) to be in the range of 0..255 (8-bit).  This fixed his problem but bothered me as to why I needed to do this.

I came up with 2 competing theories:

• You guys had secretly added UTF-8 support to TBASIC.  Modified CHR$(n) to accept 16-bit arguments and convert them to multiple UTF-8 bytes.  Modified ASC(A$,i) and MID$ to recognize UTF-8 encoded characters and reconstruct the 16-bit values.  And, were too modest to mention all of these improvements.
• The simulator was handling strings differently then real hardware.

I was getting so excited about the first theory and ignored the fact that the 2nd theory was much more plausible.

Gary D.

Thanks.

I like algorithms.  Glad I could help

Gary D*ckinson

You could try something like this to build a string from packed 16 bit data in DM[]:

a$ = ""
for i = 116 to 125
    a = dm[i]
    a$ = a$ + chr$(a)       ' least significant byte
    a = (a / 256) & &hff    ' shift right 8 bits
    a$ = a$ + chr$(a)       ' most significant byte
next

On your Modbus question.  No.  Modbus does not have a defined  mechanism to transfer strings. The String variables are not accessible by Modbus.  So packing/unpacking strings into DM and transfering the data as multiple 16 bit registers is what you must do.

Gary D*ckinson

Lorne,

Welcome to the wild world on PLCs!  

Zero is a pretty new idea.  It dates back to about 773 AD. Until then if you had nothing to sell you didn't need to count it.  If you had stuff to sell you could inventory it by counting 1,2,3...

Old computer languages like BASIC and FORTRAN considered 1 as the index of the first item in an array.  Most modern computer languages think that 0 is the index of the first item (or you can specify the starting index). Starting with 0 simplifies the math for the computer but would confuse people born before 773 AD.

TRI's PLCs tend to use 1 or +1 for lots of stuff.  There isn't a right or wrong to this, it just is what it is.  At least they are consistent.

I consider the MP4030 to be the "odd man" in this combo.  Their use of 8-bit byes versus 16-bit words for data transfer is very uncommon in PLC/industrial control circles.  It's been a long time since I have run into this sort of behavior.

It would have been nice if TRI had written more useful documentation for the MP4030 and the use of TRI native host communication protocol, but they didn't.

Good luck,

Gary D*ckinson