Internet PLC Forum

Lorne,

The use of interrupts can be tricky.  

If your goal is to respond quickly to some external event by changing an OUTPUT, the response time is dominated by the ladder logic scan rate.  The OUTPUT will not change until the end of the scan.  In thus sort of scenario, it often makes more sense to just handle the input with ladder logic.

If you have an external INPUT that wiggles at a rate greater than you can handle with ladder logic, and you need to count each wiggle, I’d suggest that you look at using the specialized high speed counter system.

In any case, I strongly urge you to build a test system to throughly exercise and test your PLC firmware.  For most of my clients, I use a second PLC to model their system.  I typically model analog signals, Modbus devices, pulsatile inputs and many other things.  

You can model high speed digital pulses using the stepper motor or PWM SYSTEM. This is what I use.

If your system's response to these interrupt inputs is critical and the failure to respond could result in Catastrophe, please test the snot out of your code.  Make certain that your code can handle input rates significantly higher then the actual system can generate.

Best regards,

Gary D*ckinson

Lorne,

I've been working with the TRI PLCs for over 14 years. I, too, struggled with their documentation.

I share your option of TRI's technical support.  They are fantastic! Very, very bright people at TRI.

90% of the PLC code that I have written is test and debug code. This is the only way to figure out how some of the stuff works.  The other 10% is actual product code for clients.

My specialty is algorithms.  Let me know if you get stumped.  I've probably already written code that may be helpful.

Gary D*ckinson

Art,

Sorry, I misread your question.

About all that makes sense for High Speed Timers is to put the "HSTIMER 2" statement in a custom function that is called on the first scan of the ladder logic.  

I see no reason to save the PV (present value) for a TIMER and attempt to restore it after the PLC reboots.

The Set Value of the TIMER is defined by in the I/O table and will be initialized when the PLC restarts.  

If, however, your program changes the SV for TIMERs and COUNTERs during the execution of the code and you need to restore the changed SV, then you need to save to EEPROM and restore the SV of these items.  

I do change the SV for TIMERs and COUNTERs to values other than what is defined in the "I/O Table" while the PLC is running.  I have clients that need to customize the behavior of a PLC based system for specific clients.  Rather than writing a different PLC program for each of these customers, I have the PLC read the system configuration from an ASCII text file stored in the PLC filesystem.  This configuration file can be changed either via the HMI attached to the PLC or by uploading via FTP a new configuration file.

I do use High Speed Timers in my PLC programming.  But I am very careful to ensure that the worst case scan time through my ladder logic program is less than the time-base of the TIMERs to ensure that the TIMER is reasonably accurate.  

Sorry for not reading your question correctly.

Gary D*ckinson

Lorne,

I thought a little more about the use of delimiters in TBASIC, and how to write code that is 100% unreadable but actually compiles and works.

The 1st half of the following code example is how I usually write PLC code.  The 2nd half is the same code but I have intentionally pushed the boundaries of common sense with how I have use delimiters to make the code unreadable.

' Custom function to print 0..99 on serial device #2
'
' This is the text that will be sent to the serial device:
'
'   00 01 02 03 04 05 06 07 08 09
'   10 11 12 13 14 15 16 17 18 19
'   20 21 22 23 24 25 26 27 28 29
'   30 31 32 33 34 35 36 37 38 39
'   40 41 42 43 44 45 46 47 48 49
'   50 51 52 53 54 55 56 57 58 59
'   60 61 62 63 64 65 66 67 68 69
'   70 71 72 73 74 75 76 77 78 79
'   80 81 82 83 84 85 86 87 88 89
'   90 91 92 93 94 95 96 97 98 99
'
print #2 "First Version"      ' Debug Message
for i = 0 to 9               ' outer loop for the 1s digits
   for j = 0 to 9            '   inner loop for the 10s digits
      print   #2 i;j;" ";      '   print each number with 2 digits and a space
   next
   print #2               '   newline at the end of each group of 10 numbers
next

' this code will produce the same results
'
print   #2
"Second" ;
print   #2
" Version"
for  i = 0
to  9  for
j = 0 to 9
print   #2
i;j ;" " ;
next print
#2    next
[/font][/color]

When run under simulations this is what is output to the simulated serial port:

First Version
00 01 02 03 04 05 06 07 08 09
10 11 12 13 14 15 16 17 18 19
20 21 22 23 24 25 26 27 28 29
30 31 32 33 34 35 36 37 38 39
40 41 42 43 44 45 46 47 48 49
50 51 52 53 54 55 56 57 58 59
60 61 62 63 64 65 66 67 68 69
70 71 72 73 74 75 76 77 78 79
80 81 82 83 84 85 86 87 88 89
90 91 92 93 94 95 96 97 98 99
Second Version
00 01 02 03 04 05 06 07 08 09
10 11 12 13 14 15 16 17 18 19
20 21 22 23 24 25 26 27 28 29
30 31 32 33 34 35 36 37 38 39
40 41 42 43 44 45 46 47 48 49
50 51 52 53 54 55 56 57 58 59
60 61 62 63 64 65 66 67 68 69
70 71 72 73 74 75 76 77 78 79
80 81 82 83 84 85 86 87 88 89
90 91 92 93 94 95 96 97 98 99
[/font][/color]

TBASIC unlike very early dialects of BASIC can have statements and expressions split over multiple program lines.  You can have multiple statements on a single line as long as you have some delimiter between them.

Arithmetic, bitwise and relational expressions are handled a little differently by the TBASIC expression parser and in most cases do not require white space delimiters.  You can write code like this and it works:
A=45/C*42+2MOD4  ' no spaces needed!!!

Wasn't this fun?

Gary D*ckinson

Lorne,

TBASIC is a TRI's programming language has syntax that is close to many other BASIC languages.

Your question about the use of delimiters is a very valid one to ask.  First I must remind you that ":" is only one of many delimiters used by TBASIC.  The other delimiters are ASCII spaces, ASCII tabs and ASCII newline characters.

The purpose of a delimiter is to allow the TBASIC compiler to be able to break the program you have written down into bits of stuff that can be understood.

Your first program statement:
IF A>B  THEN
    THEN C=D*5
ELSE
    C=D/5
ENDIF

Is not written correctly and cannot be compiled.  You are still holding on to the use of the "THEN" that I have corresponded with you about earlier. There is no reason to use "THEN" in TBASIC .  The use of "THEN" is 100% optional, however the use of THEN twice in row is 100% wrong.

First get rid of both "THEN" keywords. Your program snippet will compile:

IF A>B
    C=D*5
ELSE
    C=D/5
ENDIF

I have marked the delimiters in red for your programming snippet.  __ is where you used an ASCII space(s) as a delimiter and <CR> is where you you used an ASCII newline as a delimiter.

IF__A>B<CR>
__C=D*5<CR>
ELSE<CR>
__C=D/5<CR>
ENDIF<CR>

You will notice that you have several delimiters in a row.  You can make this program "smaller" by eliminating the extra delimiters. This is about as small as you can make your programming snippet:

IF_A>B_C=D*5_ELSE_C=D/5_ENDIF<CR>

OR (without the delimiter highlighting):

IF A>B C=D*5 ELSE C=D/5 ENDIF

Your shortened snippet will not compile as you used "IS" rather than "IF":

IS A>B: C=D*5:ELSE:C=D/5:ENDIF

OK, what about the ":" delimiter?  In many BASIC dialects the ":" was used to allow one to place multiple statements on a single line of code.  In TBASIC you can get this done with the use of the ASCII space.  I am not certain when or if the ":" delimiter is ever required by TBASIC. However, If I wanted to put the following code on a single line, I might use the ":" to remind me of the statement boundaries:

IF A>B
    C=D*5
    SetIO BIT0
ELSE
    C=D/5
    ClrIO BIT0
ENDIF

Could be written as:

IF A>B  C=D*5 : SetIO BIT0 ELSE C=D/5 : ClrIO BIT0 ENDIF

I added the " : " between the statements to make it a bit easier to read.  Please note that  I am using " : " as the delimiter rather than ":" as  some versions of the i-TriLOGI do not consistently recognize ":" as a delimiter.  TRI is aware of this and may be fixed this problem in future releases.

Your last question about:

IF SUMCV >= 27 SETIO SUCT27 ELSE CLRIO SUCT27

You have supplied all of the delimiters required by TBASIC. This code will compile and it will execute as you expect.

The key things to think about is this, "If you write code with litter or no structure, will you be able to understand or maintain this code in the future?"

Best regards,

Gary D*ckinson

OK, thought about it and I think that I can explain how TIMERs work.

1.  TIMERs are implemented in PLC firmware.
2.  Each TIMER has a data structure managed by the PLC firmware. This data
   structure for each TIMER includes these things and probably a few other items:
      TIMER SV
      TIMER PV
      TIMER control input state
      TIMER contact state

OK, with that in mind, this is how I think a TIMER works:
1. Following reset, the input state for all TIMERs is set to zero to indicate that the TIMERs are inactive.
   The contact associated with each TIMER is set to 0 to indicate that the TIMER has not timed out.
2. On the each scan of the ladder logic the evaluates the control input state for each structure during the
   ladder logic scan.  This state is maintained in the data structure associated with the TIMER.
3. If the ladder logic scan determines that the TIMER control input is 0 or false, the contact associated with the
   TIMER is set to 0 or de-asserted.
4. If the ladder logic scan detects that the TIMER control input has transitioned to l, then the TIMER is active.
   The TIMER SV is reloaded and the TIMER's contact is set to 0 or FALSE. These changes happen when the
   rung of ladder logic that controls the TIMER is executed.  These changes are visible to all other rungs of ladder
   logic that follows the rung that controls the TIMER.
5. At the start of each ladder logic scan, each TIMER that is active at the end of the previous scan may have its PV
   decremented based on either a 0.1 second or 0.01 clock. If the TIMER's PV is now 0, then the contact associated
   with this TIMER will be set asserted (set TRUE).  Please note that contact transitions for 0..1 at the start of the
   ladder logic scan and NOT at the rung of code that controls the TIMER.

The most important points to take away from this long winded guess on TIMER behavior is that a TIMER's contact is set TRUE (1) at the beginning of the scan and the contact is set FALSE (0) the ladder logic rung that controls the TIMER is evaluated.

The fact that the TIMER contact is set and cleared at different points in the execution of the ladder logic explains why the TIMER contact can be "seen" as TRUE before the ladder rung that controls the TIMER and is never seen after this rung in my one line PLC code to implement an oscillator.

This is a bit of tricky TIMER stuff but it is not broken, but it is now documented.


Best regards,

Gary D*ckinson

This is a simpler version that gets a big fat visible output pulse and is based on 2 TIMERs.  The SV for the TIMERs determine how long the OUTPUT is on and off.

I use this setup when I need a very slow (low frequency) PWM output that the PLC PWM hardware cannot support.  I just change the SV on the fly to adjust the frequency and duty cycle.

Gary D*ckinson

The first problem is that the correct Modbus register address to access DM[782] should be 1782 not 782.  The basic rule to generate a Modbus register address for DM[n] addressing is to add 1000 to "n".

If the Nano-10 responds to Modbus address 782, it is not documented as to what address 782 might contain.  I cannot explain what you are seeing if you attempt to read multiple registers from the Nano-10 starting at modbus address 782.

The internal Modbus addresses are documented (hinted at) in the Nano-10 User Manual version 7.2 in figure 14.6.1.1

I have a couple of suggestions:

• Write a PC6 program that contains a single custom function that runs on the first scan of the ladder logic. This CF should write an incrementing 16-bit pattern to each of the DM[] locations.   This is what I'd suggest:

' Fill Nano-10 DM[n] locations with a value equal to the index, "n", for each of the
'   1000 DM[] registers supported by the Nano-10
'
for i = 1 to 1000
   DM[i] = i
next
Now you know exactly what to expect when accessing any DM[] location.

• Change your Modbus TCP/IP program to use the correct registers address for DM[n].  Now see if you are actually getting the correct data from the Nano-10
• Use a Modbus test program that allows you to see exactly how the Nano-10 responds.  I have used Chipkin Automation Systems CAS Modbus Scanner for both Modbus TCP/IP and Modbus RTU with the PLCs as clients and many other Modbus devices.  This is a free program at:

http://www.chipkin.com/products/software/modbus-software/cas-modbus-scanner/
[/list]

Best of luck,

Gary D*ckinson