Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - garysdickinson

Pages: 1 ... 31 32 [33] 34
481
Technical support / Re:Time based events
« on: July 20, 2009, 08:35:46 PM »
The early suggestion on how to avoid mis-reading the TIME[] was not tested.  This code has been tested:


'Read RTC - code to access time of day registers and return CORRECT values
' in the following variables:
' DM[301] TIME[1], RTC Hours
' DM[302] TIME[2], RTC Minutes
' DM[303] TIME[3], RTC Seconds

while 1
   ' read all TIME[] registers, one time
   '
   DM[301] = TIME[1]
   DM[302] = TIME[2]
   DM[303] = TIME[3]

   ' re-read the TIME[] register and verify that they did not change
   ' from the previous set.  The whole point of this exercise is to
   ' detect and discard erronous readings that can occur becuase the PLC
   ' firmware is constanly updating these register.  It is possible to
   ' observe the following transisitons:
   '
   '   23:59:59 -> 23:59:00 -> 23:00:00 -> 00:00:00
   '
   if ((DM[301]=TIME[1]) AND (DM[302]=TIME[2]) AND (DM[303]=TIME[3]))
      return   ' time is correct, no invalid transisitons
   endif

   ' If we are here then there was a roll over between the reads of the
   ' TIME[] registers...so try it again
   '
endwhile

482
Technical support / Re:Time based events
« on: July 20, 2009, 06:29:42 PM »
One more note.  

As there is no mechanism to stop the PLC firmware from updating the RTC registers during Reads of TIME[] and DATE[] there is no mechanism to prevent the PLC firmware from changing the underlining registers during write access to the TIME[] and DATE[] registers.

I suggest that if one is trying to set the RTC time and date via TLBASIC , then one should re-read all of the registers to see that the PLC time and date registers actually got set to the values that you intended.

I hope I don't make you guys too crazy,

Gary D.

483
Technical support / Re:Time based events
« on: July 20, 2009, 06:12:02 PM »
I did a simple test with the T100MD+ PLC to see if it is possible to access TIME[1], TIME[2] and TIME[3] and "See"an invalid time.

The short answer is YES.  The same problem will occur with DATE[].

I used the following custom function to test the RTC and the online monitoring to examine the contents of the DM[] array:

' Set RTC to 23:59:59
TIME[1]=23
TIME[2]=59
TIME[3]=59

' Read all time registers quickly and store results in DM[]
for i = 1 to 3999 step 3
    DM[i+0] = TIME[1]
    DM[i+1] = TIME[2]
    DM[i+2] = TIME[3]
NEXT

' Hunt through DM[] looking for rollover event.
' I points at change in time array
'
for i = 3 to 3999 step 3
    if DM = 0
        return
    endif
next


With this simple test, I have observed the following transition in the time registers:

23:59:59 -> 23:59:00

and on some occasions

23:59:59 -> to 23:00:00

What I never observed was a clean transition from

23:59:59 to 00:00:00 !!!


Because there is no mechanism in ensure that all 3 TIME[] registers can be accessed without the possibility of a roll over event, I would strongly suggest the following approach:



' this code accesses the TIME[] registers and returns
' with DM[1] = Hours, DM[2] = Minutes and DM[3] = seconds
'
' DM[4..6] are used as scratch registers
'
while 1
    for i = 1 to 3              ' read time registers quickly
        DM = TIME
    next
    for i = 4 to 6              ' read them a 2nd time
        DM = TIME
    next

    if (DM[1] = DM[4]) AND (DM[2] = DM[5]) AND (DM[3] = DM[6])
        return                   ' good read, you are done
    endif

    ' if you are here, then a roll over occurred...
    '
    ' Read all the registers again...
    '
endwhile


484
Technical support / Re:Time based events
« on: July 19, 2009, 07:05:57 PM »
I use this code for controlling lighting events and multiple pumps for a salt water aquarium.  I can supply other bits of the code if this would be useful

It is possible that tobor0216 is seeing a real problem.  

My experience with physical RTCs (used on old PC mother boards or your MX-RTC) HAVE problems with roll over events.  With these RTCs the problem shows up like this:

AT 23:59:59 it was possible to read the time as 23:00:00 if your read the hours register first and the RTC updated the seconds and minutes register before one was able to read them. This problem happens because:
  • The HR:MM:SS registers were linked such that the overflow of seconds from XX:XX:59 to XX:XX:00 results in a ripple carry into the minutes register and the minutes register carried into the hours regsiter.
  • Each register HR:MM:SS required a separate 8 bit (or multiple 4 bit) access by the CPU.
  • There was no mechanism to hold (synchronize) the registers so that the CPU could read all 3 of them and ensure that an ripple did not occur between the access of the first register and the last.
One firmware mechanism to cope with this problem was to read all three registers twice and then compare the values.  If there were any differences then assume that a register was updated and reading until two successive reads of the compelee register set gave the same results.

I bring up this issue as
  • I have not exhaustively tested the TIME[] mechanism in your PLCs.  
  • There is no documented interlock mechanism in TLBASIC to ensure that if I read TIME[1], TIME[2] and TIME[3] that there will be no rollover between access to the the HR, MIN and SEC registers.




485
Technical support / Re:Time based events
« on: July 18, 2009, 10:54:02 AM »
This is the code that I use to manage 8 time clock events.
I store the start and stop times in the DM[] array. The use of the DM[] array allowed me to make the stop/start times easily changeale (not hard coded).  In fact, I actually store the stop/start times in EEPROM and copy the values from EEPROM into DM[1..17] on start up.  

The 8 relays that are affected by the routine are in sequential order are relays  #17 through #24.  These  8 relays are accessed using the setbit and clrbit.

In this example I am only worried about starting and stopping things with a resolution of 1 minute so I only look at time[1] and time[2].  This routine is called every 30 seconds to ensure that I don't miss an event (Nyquest limit).

If you need to make your time clock accurate to 1 second, then you will need to take time[3] into account.  You will need to call your routine at least twice each second.

Please note that I use ">=" and "<" to compare my stop/start times against the current time and do not use "=".  This ensures that if the PLC is started (or reset) in the middle of a start/stop time period that the outputs (relays) will be set/cleared correctly and not have to wait 24 hrs for the exact "start time".

Please also note that I worry about start/stop events that span midnight (00:00:00) so that these events are handled correctly.



'TimeChk - Called periodically to manage relays 17..23
'Relays are set on/off based on the current time and the
'stop/start times stored in dm[1..17]
'
t=time[1]*100+time[2] ' t is current time in scaled minutes
n=1 ' index into dm[] for start/stop pairs
for i = 0 to 7 ' each relay
  if dm[n]<=dm[n+1]
    'ON period does not span midnight
    if (t>=dm[n]) and (t<dm[n+1])
      setbit RELAY[2],i
    else
      clrbit RELAY[2],i
    endif
  else
    'ON period spans midnight
    if (t>=dm[n+1]) and (t<dm[n])
      clrbit RELAY[2],i
    else
      setbit RELAY[2],i
    endif
  endif
  n=n+2 ' next stop/start pair
next

486
Technical support / Re:Time Delay Drop Out Relay
« on: June 09, 2009, 11:56:13 PM »
There are several ways to do this.  I'll present a fairly generic method that will work with most all PLCs.

In the following example:

I1, is the INPUT
O1 is the OUTPUT
Timer1 is a TIMER that determines how long to keep the OUPUT relay energized after the input goes inactive.

The first rung of the ladder logic causes Timer1 to go active (TRUE) only after the INPUT, I1, has inactive (FALSE) for the time value that is set by Timer1.

The second rung is of the ladder logic is typical ladder logic latching relay.  When I1 is TRUE O1 goes TRUE.  The OUTPUT, O1, is wrapped back as an input term to the O1.  The the Timer1 NC term (|/|) is used to reset output O1 when Timer1 goes active.


    I1
--|/|------------------------(Timer1)

    I1                Timer1
--||-------+---|/|------------(O1)
              |
  O1        |
--||-----+

Gary D

487
Yes my file contains both CR and LF

This is the contents of my one line file in ASCII and HEX:

ABCD                   <-- ASCII
414243430D0A   <-- Hex dump          

This is what the PLC "sees" after Arbitration with STX/ACK, sending the <REMOTE> and <READ ReadFile.txt> then waiting 1 second:

ABCD<OK>
414243443C4F4B3E0D

This is the TBASIC code that I use to display the results of the READ file service on the LCD:

        A$ = ""
   H$ = ""
   I = INCOMM(1)
   WHILE I<>-1
      A$ = A$ + CHR$(I)
      H$ = H$ + HEX$(I,2)
      I = INCOMM(1)
   ENDWHILE

   SETLCD 2,1,A$               ' Display ASCII String
   SETLCD 3,1,H$               ' Display HEX String

I'm using the INCOMM(1) command as it does less processing to the characters received on the COMM1 port.

Is there a possibility that the changes to support Unicode characters have affected the TLServer 3.15?

488
I'm attempting to use the READ file service provided by TLServer V3.15

I'm using an old T100MD+1616 r42 PLC.  I'm using the XServer to conenct the PLC's RS-232 to ethernet.  I'm using TLServer V3.15.  The PC is running Vista (32bit)

I've created a ASCII file that contains two lines of text that are terminated with CR/LF pairs:

    01 Text<cr><lf>
    02 Text<cr><lf>


The READ command returns the following:

    01 Text02 Text<OK><cr>

I have used both INPUT$(1) and INCOMM(1) commands to verify this behavior.

What I see is that ALL line termination characters are stripped from the text file.  I understand that the "<OK><cr>" is the acknowledgement string from the TLServer.

This behavior is not what is documented in TLServer "Help":

Upon receiving this command and if the specified [filename] is successfully opened, the TLServer will begin sending all the ASCII characters contained in the text file to the PLC. Note that line breaks in a text file are sent to the PLC as CR character only and not as a CR+LF pair. As such, your PLC program can easily use the INPUT$(1) command to read in all the CR-terminated text string one string at a time and then interpret or convert the data as necessary. After sending out the last byte in the data file to the PLC, the TLServer will send a CR-terminated acknowledgement string "<OK>" to the PLC to signal that the READ command have been properly completed.


489
Technical support / Re:Set/Clear of RTC.ERR
« on: February 19, 2009, 08:50:58 AM »
Thanks,

This makes perfect sense, my test board is r42.



490
Technical support / Re:Actual [UpCtr] Counter value
« on: February 18, 2009, 03:35:22 PM »
The preset value of a counter can be accessed in TBASIC.  The counters appear as an array of integers named ctrPV[n] (where "n" is the counter number 1..256).

If you wanted to display the value of counter #1 on the LCD you could do something like this:
 
SETLCD 1,1, STR$(ctrPV[1])

If you wanted to test if the current value of counter #21 is equal to 5:

IF ctrPV[21] = 5
    ' do something here with this knowledge
    '
ENDIF

If you wanted to force the current value of counter #2 to the value 11:

ctrPV[2] = 11

Have fun.

491
Technical support / Set/Clear of RTC.ERR
« on: February 18, 2009, 10:50:47 AM »
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).

492
Technical support / Re:TLServer File Services and On-line Monitoring
« on: February 14, 2009, 09:25:05 AM »
Thanks for the info on the XA command.  I suspect that these XA commands are used by the On-Line monitoring and that the XA commands  transfers binary (not just printable ASCII) data.  This behavior precludes the use of STX/ACK arbitration.

Is there any mechanism that the PLC can use to detect if On- line monitoring is in progress?  An undocumented TBasic command or a special bit that ladder logic could "look at" would be great.

I've worked with the sample code that was provided for the XServer and found that these algorithms do not work with On-line monitoring.  I've spent a couple of days attempting to develop more reliable algorithms but the XA command seems to be the one problem that I cannot work around.

Thanks again for your help.

493
Technical support / Re:TLServer File Services and On-line Monitoring
« on: February 13, 2009, 03:54:09 PM »
Thanks for reminding me about the F-Series PLCs, this may be the best solution.

I have been experimenting with the STX/ACK arbitration and clearly understand that it doesn't work reliably.  This makes the use of the NS commands very difficult if the same COMM port is used for On-line monitoring.

I do have one question, "What is an XA command?"

In some cases where the STX/ACK arbitration appears to work, then I issue the NS command for Apending to a file, I sometimes find in the PLC Comm #1 input buffer the following string:

     "@01XA58"

The next string in the the buffer is "<OK>", however the NS command did not complete correctly and the data appended to the file is corrupt.

I believe that this "XA" command was sent by the TLServer to the PLC after sucessfully arbitrating with the STX/ACK handshake.  It seems as if the TLServer grants control of the COMM port (STX/ACK) but then forgets and resumes sending commands to the PLC without waiting for the "</>" terminator or a significant timeout.

I can't find any reference to the "XA" command.

Thanks for your advice.

494
Technical support / TLServer File Services and On-line Monitoring
« on: February 09, 2009, 10:19:35 PM »
I'm working with T100MD+1616 hardware and would like to log PLC data to a PC using the TLServer and the <APPEND xxx.txt> mechanism.

The problem that I am having is that I'm using the same COMM #1 port for both debug (online monitoring) and the <APPEND xxx.txt> activity.  It believe that the data streams for the <APPEND xxx> file services are getting intermixed with the On-Line Monitoring requests to "see" what's going on with the PLC.

The TLServer help files state:

The TLServer will close the file after it receives the end-of-service tag "</>" from the PLC and it will in turn send a "<OK>" tag to the PLC to acknowledge that the APPEND  request has been successfully completed. It is up to your PLC program to check for the "<OK>" tag to determine if it the service it requested have been completed successfully.

The Help file gives no suggestion on how the PLC program should check for the "<OK>" tag.

I use the following code to read the <OK> tag I really mess up the On-Line Monitoring:

' Get Response from TLServer
'
A$=""
N=0
I = INCOMM(1)
WHILE I<>-1
    A$=A$+CHR$(I)
    N=N+1
    I = INCOMM(1)
ENDWHILE

Is there a special (correct) way to check for the "<OK>" token?

Is the <OK> tag buffered differently from the commands send/received as a result of the On-Line Monitoring?  Is there a special TLBasic function that I should use?

Would I have less problems if I used the XServer rather than the RS-232 connection?

495
Technical support / Use of MDS100-BW and I-7017 on same RS485 port?
« on: February 07, 2009, 06:14:16 PM »
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?

Pages: 1 ... 31 32 [33] 34