Internet PLC Forum

In studying the example PC6 file, "TimeServer", I noticed that the programmer set DATE[3] (day of month register) to a value of 0 to back up the RTC year, month, day registers.  

The end result, is that the RTC DATE[1], DATE[2] and DATE[3] registers will be backed up to the last day of the previous month.  The year register may also be affected.

The following TBASIC code:

???DATE[1] = 2012
???DATE[2] = 1
???DATE[3] = 0???

Will program the RTC to 12/31/2011. This effectively backs the RTC up one day.  The TBASIC programmer doesn't have to worry about the number of days in each month.  I haven't tested it for leap year behavior.

Programming the DATE[1] register with values less than 0 appear to advance the date way into the future.  Negative numbers are not handled well by the PLC firmware.  This is not a problem.  Backing up by a single day is perfect.

I did a little work and discovered that If I program DATE[3] to a value greater than the maximum days possible for the current month and year will advance the RTC year, month and day registers.

The following TBASIC code:

???DATE[1] = 2011
???DATE[2] = 12
???DATE[3] = 32???' There are 31 days in December...

As there are only 31 days in December, this will advance the RTC to one day beyond the last day in December. The RTC will be programmed to 1/1/2012.

In the previous example, if DATE[3] is programed to 33, this will advance the RTC by 2 days.  There is a bit of a pattern to
this...

OK.  Also very cool.  

This functionality is very useful, nearly indispensable when attempting to set the RTC for local time using an external time server such as NIST.  The NIST server provides time but it is in UTC and there are many cases where the local date is either ahead of UTC or behind UTC by a single day.

It might be nice to formally document these behaviors.  I suspect that the DATE[3] behavior exists in most of your PLCs.  I only have access to a small sample of your products.

The simulator in TriLOGI V6.40 does not emulate these RTC behaviors.

In the spirit of full disclosure, are there any similar undocumented math capabilities in the TIME[] registers?

I ask this because there are a few places crazier than California.  There are a lot of spots in the world that local time is not on hour boundaries. Adelaide Australia is +9:30 away form UTC... and they're only a little crazy!

Thanks for letting me rant.

Gary D.

I attempted to interface a mechanical rotary encoder to a T100MD+ PLC.  The goal was to use the encoder for a simple input control for PLC based project.  Just one knob and one or two external push button switches.

These encoders are typically used as volume controls on car radios and many other consumer devices.  The encoder that I was using is a EVQ-WTE series encoder manufactured by Panasonic.  The encoder act just like typical 2-bit quadrature encoders with A/B outputs that are out of phase by 90 degrees.   The encoder has 30 mechanical detents for each revolution of the knob but only produces 15 complete output cycles.

The encoder waveforms look like this:

            +----+----+------ Mechanical Detent
            |     |     |
            V     V     V        
      ---+     +----+     +---
  A      |     |     |     |
         +----+     +----+

         ---+     +----+     +---
  B         |     |     |     |
           +----+      +----+
              ^         ^
              |         |
              +--------+------ HSC counts here

  A/B Phase relation for C.W. Rotation



I tried 2 different approaches to interface this encoder to the PLC:

1.  Ladder logic.  This failed because the "debounce" logic used for the PLC INPUT circuits limits the speed that the the encoder can be operated and the ladder logic scan time is a  too slow to catch all of the transitions on the A/B inputs.

If the knob is turned quickly at a speed of about 1 RPM the phase difference of A/B can be as little a 2.5 ms.

I used the following ladder logic.  I used a Sequencer because it is easy to initialize to a value of "0" without having to use a custom function.


 |
 | 1st.Scan                              Seq1:0
 +-----||--------------------------------[StepN]
 |
 |     A                                  CLKA
 +-----||--------------------------------[dDIFU]
 |
 |      A                                 CLKAN
 +-----|/|-------------------------------[dDIFU]
 |
 |    CLKA     B                          Seq1
 +-----||-----|/|---+--------------------[Upctr]
 |                   |
 |    CLKAN   B      |
 +-----||-----||----+
 |
 |    CLKA    B                           Seq1
 +-----||-----||------+-----------------[Cnctr]
 |                    |
 |    CLKAN    B      |
 +-----||-----|/|-----+
 |
 |


2. High Speed Sequencer.  Using HSCDEF 2,2,32000 in a custom function and connected the A and B phase signals to input pins 5 and 6.

The high speed sequencer only counts on the positive transitions of the A phase.   As a result, for every two clicks (mechanical detents) on the encoder the HSCPV[2] will count up/down only one time.  

The good news is that the HSC mechanism is fast enough for my low speed counter application.  Unfortunately the HSC only counts 1/2 of the time!

3. My next experiment is to use both HSC #1 and HSC#2 to connect to the mechanical encoder.  I will connect the encoder A/B inputs directly to HSC #1.  I will connect inverted versions of A/B (ULN2003?) to HSC #1.  I will then use a custom function to calculate the total count T:

    T = hscPV[1] + hscPV[2]

QUESTION  1:

Is there a mechanism to configure the High Speed Counters for the M series of the F series to count on both transitions of the A phase?  Look at my ladder logic for an example of how this is done.


QUESTION 2:

Do you have any other suggestions on how to get a low speed quadrature encoder to work with your PLCs?

QUESTION 3:

Is there some easier mechanism for me to draw waveforms on your YaBB system?  I change the fonts to "Courier" but your BB system has issues with ASCII spaces (0x20) and does not treat them as having the same horizontal width as other printable characters.  This makes it impossible to do nice ASCII artwork.

Thanks,

Gary D.

Is there a way to set/clear the RTC.ERR using ladder logic or custom functions? I'd like to clear this bit after setting the TIME[] and DATE[] variables.

I notice that the RTC.ERR bit is cleared via the "Set PLC's Real Time Clock" diaglog in i-TRiLOGI.

I can load the TIME[] and DATE[] with correct time/data info by use of the <READ RTC> NS command.  The writing o the TIME[] and DATE[] values does not effect the RTC.ERR status.

Ladder logic can use "RTC.ERROR" as a contact but cannot use this bit at the end of the logic as a COIL (output, relay, ...) nor can it use "RTC.ERROR" as the target for a functions (latch/clear/Reset).

I've got a I-7017 connected to an T100MD1616+ PLC.  I'd like to add the MDS100-BW to the same RS-485 port.

Can the MDS100 co-exist with the I-7017 on the same RS-485?

Will there be an option to reduce the font size (or use a fixed pitch font) when printing I/O tables?  

Long, but legal, names do not fit into the columns and overlap with the next column.

Example, "F1Key_EDGE" as a Input name will print across both the Inputs and Outputs column.