Internet PLC Forum

I notice that you are using:

CLRIO NEXT_CALL  <-- first line of custom function
SETIO NEXT_CALL  <-- almost last line of custom function

Are you expecting that the RELAY NEXT_CALL will generate a pulse that will advance a COUNTER?  If yes, then this will not work. The ladder logic is suspended until your custom function completes, so the ladder logic will only "see" the final state of NEXT_CALL

If you are going to advance a sequencer no more often than once per second you could do something like the following.  In your custom function you could do a CLRIO NEXT_CALL to disable the sequencer from advancing.
 

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 just started using V6.40 build 02.  I noticed in the notes on the download page that the problem with shifting I/O up/down in the I/O Table had been fixed with custom functions.

It may have been "fixed" but it is now broken.

I find that with this version that if I have 2 custom functions:

  1-ConnectNIST
  2-ReadNIST

Then highlight "1=ConnectNIST", right click and select "Shift I/O Down" then I get the following:

  1-
  2-ConnectNIST
  3-ReadNIST

Everything is correct! The labels and the custom functions moved down.  Custom function #1 is blank.  

Now I create the name and contents for the new custom function #1.  I'll call it "NewFunc".

Now if I highlight "1-" (new empty custom function), right click and select "Shift I/O Up", things go wrong.  

The I/O labels are shifted Up correctly, but the contents of the custom functions are not 100% correct:

This is what I see after the shift up:

1-ConnectNIST <- Contents of  previous 1-NewFunc  WRONG!!! I/O label was moved, the OLD custom function code has not been overwritten.

2-ReadNIST <- Contents of  3-ReadNIST   I/O labels are correct.  Everthing is CORRECT!!!

I believe that the code that moves the contents of the custom functions "UP" does not start at the right point in the array (or list) of custom functions.

Gary Dickinson

Good to hear that you are making progress on your noise problems.

Another thing you should consider is electrical grounding.  

If your system operates "correctly" when you laptop is running off batteries but "fails" when plugged into an AC outlet, then it sounds like you have an grounding issue.

When your laptop is connected to a grounded AC outlet, I suspect that you may be getting excessive current flowing through the RS-232 Signal GND.  This current then flows through the PC's AC cord. When you computer is disconnected from the AC outlet, this breaks the current path.

Plug your laptop into the AC outlet and disconnect the RS-232 cable at the PLC .  Use a DVM and measure the voltage  difference between the RS-232 Signal GND (pin #5 on the DB-9 connector) on the cable and and at the PLC socket.  

If you measure more than a few millivollts AC or DC then you have a grounding problem.  This grounding problem can result in communication issues with RS-232 signaling.  I have personally seen RS-232 cables melt as a result of AC grounding problems.

If you have an issue, you need to fix it.  Ensure that your PLC, power supplies and servo controller grounds are bonded together at a single point.  Use big fat wires to minimize voltage drops.

The AC protective ground (3rd pin on the plug) should be connected to this single point.  Any exposed metal in your system should also be tied to the protective ground (electrical safety issue).

Ensure that the everything that plugs into AC power is at the same ground potential. You may want to plug everything into a single plug strip.

Good Luck,

Gary D.



 

SPAM

I've got a couple of suggestions/question on your data logging issue:

• What is the maximum data value that you need to save?  If it is in the range of 0..255 (8 bit) you could pack two 8-bit values into each 16-bit DM[] entry.
• There is probably no need to save the 24 hour summation. You can generate this data from the 30 minute samples. This will save you a little space.
• The T100MD also has EEPROM memory that would hold an additional 1700 16-bit integers.
• Use an external PC connected to the T100MD via RS232 or RS485 to a PC to do the data logging.  I've used a SCADA program named, DaqFactory, from www.azeotech.com to do all of the data logging for one of my projects.

Good luck,

Gary D

Danier,

I am having difficulty understanding your question.   The English translation is of you question does not make much sense.

Can you describe the problem using less language?  Perhaps a flowchart, state diagram or a timing diagram?

This is an improvement on the marquee display code.  I've included both the ladder logic to update the display as well as the two custom functions.  

I know that this is not exactly the question that Danier posed. But it does give an example of how to invoke a custom function on a periodic basis.


  1st.Scan                                        InitMarquee
----||-----------------------------------------------{dCusF}

  Clk.0.2s                                     DisplayMarguee
----||-----------------------------------------------{dCusfF}


This is the code for the InitMarquee custom function:

' InitMarquee
'
' String in A$ is used as to generate a scrolling marquee
'
' On exit: z holds the current index into the A$ to be displayed
'          y holds lenght of marquee field
'
a$ = "Buenos dias. Bienvenidos a la empresa."
z = 1       ' Starting index into A$      
y = 16      ' display field width

This is the code for the DisplayMarquee custom function:

' DisplayMarquee
'
' On entry: A$ is the string to display
'          z holds the current index into the A$ to be displayed
'          y holds length of marquee field
'
'
'
' On exit: B$ holds string that is displayed
'          z is updated to the next position to display.
'          y is unchanged
'          A$ is unchanged
'
'
B$ = MID$(A$,z,y)

' Pad B$ to field with with " " (ASCII space)
'   Spaces are added to ensure that length of B$ is always
'   equal to the display field width.  This ensures that
'   each SETLCD command updates every character on the display.
'
' Note: the is sort of a lazy way to pad the string...
'
WHILE (LEN(B$) < Y)
   B$ = B$ + " "
ENDWHILE

' Next index
'
Z = Z + 1
IF (Z > LEN(A$))
   Z = 1         ' reset index to beginning of the string
ENDIF

SETLCD 1, 1, B$      ' display the string