Internet PLC Forum

cdenk,

On the rotary encoder, it had 32 steps per rev.  2 digit numbers took a little over 6 spins.  The encoder is not a perfect match for the T100MD+ as these PLCs don't support the decode mode required to get all 32 steps.  Ladder logic was not fast enough to track the transitions when the encoder was moved rapidly.  I used interrupt routines to interface to the encoder.

On the HMI keypad input I took an approach where the parameter to be edited was converted to a string, edited as a string and converted only back to a number for storage/use.

As an example for a time of day field:

• This field was stored in DM[_x] as a scaled integer.  8:31 was stored as 831 ( multiply the hours by 100 and then add in the minutes).
• To edit this field, I convert the scaled integer back into a text string using the STR$(DM[_x],4) function.  The resulting sting was " 831".  Note the leading space, the length of the string must always be constant at 4 for my time fields.
• The custom function that updates the LCD display inserts a ":" as it write to the display.  The ":" never appears in the string.
• If the user enters a digit, 0..9, the old string is shifted to the left and the new digit is appended onto the right end of the string.  If the string started as "0831" and the user presses the "9" key the string will become "8319".
• The delete key causes the number to be shifted to the right.  If the string is now "8319", pressing the delete key gets you "0831"
• Pressing the ENTER key, gets the field validated and converted back into a integer for storage in DM[_x].

The approach seems convoluted, but its works well with TBASIC and I used the same editing function for all of my input fields.

This is the input handler shared by all of the numeric fields:

' Edits X$
'
' X$ is updated, X is set to 1 to indicate that input is complete
'
DM[3900] = INPUT[3]  ' Get data from input #33-48

IF TESTBIT(DM[3900],10)
  ' <Del> key has been pressed
  '
  X$ = "0"+MID$(X$,1,LEN(X$)-1)
  X = 0 ' More Input to come
  RETURN
ENDIF

IF TESTBIT(DM[3900],11)
  ' <Enter> key has been pressed. Input is complete
  '
  X = 1 ' Done with input
  RETURN
ENDIF

' OK it must be a Number key that was pressed
' Figure out which one it was...
'
FOR Z = 0 to 10
  IF TESTBIT(DM[3900],Z)
    X$ = MID$(X$,2,LEN(X$)-1)+STR$(Z)
    X = 0 ' More Input to come
    RETURN
  ENDIF
NEXT


Good luck,

Gary D

Good luck on finding the culprit.

The PLC firmware behaves as if everything is a single thread.  So there is no real mechanism to allow custom functions to have a life of their own.

About all you can do is ensure that your custom functions execute quickly and evoke them carefully (only when needed).

I never poll for an external event in a custom function nor waste time using Delay statements.  I, typically, implement this type of code using a state machine using the PLC Sequencer logic and custom functions to handle what can't be done in Ladder logic.

I've got a big system that uses external A/D converter connected to the PLC via RS-485.  This RS-485 protocol is similar to ModBus in that a command is sent to request data from the A/D converter.  If I don't get a response from the A/D converter or I get a crappy response, then I set a RELAY to indicate that the A/D converter has failed.  This same RELAY is used by the Ladder logic to block any future calls to the A/D read custom function.

I divide big time consuming custom functions up into smaller pieces. I use RELAYS set by each custom function to start the next custom function on the following scan cycle.  This is typical:

• The custom function to get raw A/D data is invoked once a minute. If there is a timeout or crappy data is returned, this function sets one or more RELAY(s) to indicate the failure.
• On the next cycle another custom function converts the A/D data from an ASCII string to several scaled integer values.
• On the next cycle a custom function validates the integer values.  If the values are wacky, I RELAY(s) are set to indicate that either the failure. The system has fall back modes to keep things safe in the event of sensor failures.
• On the next scan cycle I manage active control of heaters, chillers, fans and lighting based on the validated A/D values.
• On the last scan a custom function updates a LCD display.

This may sound like a lot of work, and it is. However it allows me to do a lot of computing without causing the PLC to become non-responsive to rapidly changing inputs.

Have a good weekend,

Gary D

Look at the end forum entry "Debounce Interupt ??" for a two different approaches for measuring the PLC scan time

It's pretty hard with using ladder logic to bog the PLC down to the point that it can miss an input generated by a human finger.

Instrument your code and figure out where the PLC is spending it's time.

Gary D.

cdenk,

You've done well with your instrumentation.  The high resolution timer is an excellent trick.   Tracking the maximum time was even better.

I often wiggle a PLC output bit using a single bit of ladder logic. I'll monitor the output with an old school oscilloscope.  Output16 will change state on every scan:

  Output16                                     Output16
---|\|-------------------------------(OUT)

With your calculation of a 17.8 ms scan period, your program doesn't seem to have put a huge burden on the PLC.  This translates to a scan frequency of over 56 Hz.  This should be plenty fast enough to not miss your contact closure.

I would think that you shouldn't need to use the interrupt mechanism to deal with your water meter.   A normal input pin should work fine.

Well done,

Gary d.

cdenk,

I done some more thinking on how you might use the interrupt input with a mechanically noisy input.  

I'd suggest adding a bit of ladder logic to mask the bounces and a couple lines to your interrupt code so that it only counts the first bounce as being important.

In the following example Mask is a RELAY used to communicate between your ladder logic and interrupt routine.  Timer1 used to mask the entire time that the contact is ON including all of the bounces.  I'd suggest programming the SV to 10 (1 second) to mask any bounces of both the closing and the opening of the contact.  EnableInts is a NEW custom function to re-enable the interrupt logic once the contacts are known to be no longer bouncing.

OK, first the ladder logic:

  Mask                      Timer1
---||------------------(TIM)

  Timer1                     Mask
---||--------------+---[Clear]
                           |
                           |     EnableInts
                           +---{dCusF}

                       
Now the change to the interrupt code:

INTROFF 1      ' Disable interrupts
SetIO MASK   ' start the event mask timer
'
' the rest of the interrupt code goes here.

New custom functions EnableInts:

INTRDEF 1, fn_num, 1


Give this a try.

Gary D.

I have a couple suggestions on signal debounce:

• Use a normal input pin and ladder logic.  When used this way, your input signal is debounced by the PLC's firmware/hardware.  You get this for free.  The frequency of your input is not fast enough to necessitate the use of an interrupt routine.  Relay logic will get the job done, easily.
• Externally filter your switch by adding a 100 Ohm resistor in series with the input pin and add a 10 uF 35VDC capacitor from the input pin to ground.  The capacitor works in conjunction with the pull-up resistor that is part of the PLC input structure. The 100 Ohm resistor is used to limit the discharge current from the capacitor to a level that will not weld your external switch shut.  If you go down this road, be aware that this is a "kludgey" fix for a problem that you don't need to fix...

Good Luck,

Gary D.

Scroll down to the end for a brute force integer square root algorithm.

I have a couple of questions that you need to answer when considering RMS calculations use a TriLog PLC:

• How quickly does your ADC input change?
• What is the "shape" of the input waveform?  Sine, square, triangle, random?
• Is there you input a pure AC waveform? Is there a DC component?

The reason I ask the first question is that if you are trying to look at an input that changes quickly (50/60Hz) the PLC may not be fast enough or able to sample consistently enough to get data that you can use for your computations.

The reason I ask the second question is simple: if the input waveform has a predictable "shape" you don't need to do a formal RMS calculation, just a simple multiply of a constant.

The third question is a test.  If you don't know why I asked this question, you don't need to compute RMS values nor do you need a square root algorithm.


OK, as promised a brute force algorithm





' Integer Square Root algorithm
'
' X is argument
'
' Temp variables used:
'   T temporary root
'   A temporary add
'   B temporary result
'
' On Exit
'   R is calculated square root
'
R = 0
A = 32768

WHILE (A)
    T = R + A
    B = T * T
    IF (B <= X)
        R = T
    ENDIF
    A = A/2
ENDWHILE


[/color]

Good luck,

Gary

Lucas,

You ask very good questions.   I've worked with the T100MD series PLCs for a number of years.  I can give you a answers to many of your questions.


- What is the maximum scan frequency of the ladder scan?

With the following single rung program running on a T100MD+1616:

   Output1                    Output1
----|\|------------------------(OUT)

Output 1 runs at 207Hz (4.84mS period).  This implies that the scan speed is approximately 414Hz (2.42mS period).  There is some jitter in the waveform, which suggests that the PLC CPU is handling some periodic interrupt.  RTC or periodic timer is my guess.

If I have a single ladder, with a single ladder element tied to an input channel, how fast can I pulse the input and have the PLC catch the pulse?

I don't have a setup to measure this.  My experience has been that input events that that run faster than about 15Hz with a 50% duty cycle tend to get lost.  My guess on the input speed limitation has to do with the logic that the PLC uses to debounce inputs.  

The PLC assumes that you have a bouncy (noisy) mechanical switch connected to the physical input to the PLC.  I suspect that they do some nature of digital filtering that requires an input to be stable for some number of scan periods before the ladder logic "sees" the new input state.

The PLC has some specialized handling for a limited number of inputs for handling high speed external events.  Think look at the documentation for high speed counters, quadrature encoders, and interrupt handling that invokes a TBASIC function based on an edge transition on a specific input pin.

The "F" Series PLCs are said to be significantly faster.  They are based on a much newer microprocessor core.  I suspect ARM9 or something similar.

- What sort of performance hit is expected with an linearly increasing ladder rung count? Say each ladder rung is uniform, and of the simple sort described above.

I duplicated the first rung and changed only the OUTPUT associated with each new rung, I got the following timings:
#Rungs Period mS
  1         4.84
  2         4.85
  4         4.90
  8         5.08
You can do the linear regression work, but for simple ladder logic, the big time hit is probably saving the input state for all physical inputs at the beginning of the scan and then updating all of the physical outputs at the end of the scan.

- What is the relative performance hit of implementing functionality in custom function BASIC versus ladder logic-triggered RELAYS? What is the performance hit involved with using logical BASIC conditionals versus implementing multiple ladder rungs? (By BASIC I'm referring to if/else if/then/else conditional logic blocks)

Ladder logic is significantly faster than BASIC for manipulating I/O (bit logic).  I do not have a test case for this.
If I get into situations that have large computationally dense BASIC code, I often break it into smaller chunks spread across several scan cycles.  There are many games that can be played to get the most out of these PLCs.

- Is there a location where I can find the operating specifications of the T100MD-2424? I'm looking for a datasheet with operational characteristics, more so than an "installation" or "operation" guide.

No.  

Gary D.