Internet PLC Forum

I got bored and decided to do some recreational PLC coding and decided to write a Tic Tac Toe program in ladder logic.  

To make the problem more challenging I decided to attempt to write the code without using custom functions, just 100% ladder logic.  

This is where I got into some issues with the [ILock] and [ILoff] functions.  Turns out that they are not broken, but I was transfixed by the example in section 9.3.5. of the TL6ReferenceManual.  

 [ILock] and [ILoff] turned out to not be very useful for my purposes, but I'd like to know how to program the "Equivalent Circuit".  I have tried everything, but I can't build this circuit with i-TRiLOGI 6 or 7.

Best regards,

Gary D*ckinson

I use the extended file system as a method to update PLC settings via text files. The text files are uploaded to the  PLC via FTP. The PLC code checks for the existence of a new configuration file, periodically.  If a new file is found, the PLC code opens the file for read, extracts the new configuration data and then deletes the file.

The small problem is that it is difficult to tell if a file exists.  The filesystem documentation suggests that reading the value returned from the status(2) function will indicate if the command was successful.  A value of "1" indicates success.

PRINT #8 "<READ Z000.TXT>"   ' Attempt to open file
s = status(2)
[/color][/font]

The call to status(2) will return a 1, to indicate success, under more conditions that you might think. I get a value of 1 for all of the following:

• File does not exist
• File exists and contains no data
• File exists and contains data

It is not possible to determine if a file exists by issuing the "<READ xxxx>" command. In fact I have found no way to determine if a file exists.  It is possible to determine the size of a file after you have "successfully" opened it with the "<READ xxxx>" command using the status(19) function.

Status(19) returns 0 for non-existent files.  Status(19), also, returns 0 if the file exists but hold no data.  For my purposes, an empty file is about as useless to me as a non-existent file.


PRINT #8 "<READ Z000.TXT>"   ' Attempt to open file for read

if status(2) <> 1
   ' File may be already open
   '
   PRINT #8 "</>"         ' Close  file
   return               '   and bail out
endif

if status(19) = 0
   ' File contains no data or it does not exist. You can't actually tell...
   '
   PRINT #8 "</>"         ' Close file
   return               '   and bail out
endif

' we got here because the file exists and contains data
'
' what follows is just test code to allow me to inspect the contents
' of small text files
'
for i = 1 to 26            ' write null strings to A$..Z$
   $$ = ""
next

' read at most 26 strings from the file and place then in A$..Z$
'
for i = 1 to 26
   $$ = INPUT$(8)
   if status(2) = 255
      exit      ' end of file reached,  break out of for loop
   endif
next

PRINT #8 "</>"      ' close file
[/color][/font]

Just some hints on the extended filesystem behavior.

Gary D*ickinson

I am attempting to debug a problem with an FMD88-10 PLC located in another continent.  My client describes the problem as the PLC being "paused".  The behavior that he is describing is consistent with a run-time error.  

I am working to get more accurate information about the issue from my client. But this will take both time and patience on my part.  I seem to not be blessed with much of either...

So in the mean time, I am trying to "instrument" the clients PLC code to log the problem.  I think that there are a few things that I can look for:

• User-defined runtime Error: defining an interrupt handler for run-time errors using the INTRDEF 100, n statement.
• Watch dog timer.  

So here are my questions about INTRDEF to catch a run-time error

• With the INTRDEF approach, how does the custom function "know" what triggered the run-time error?  
• Because CFs on the FMD88-10 do not accept arguments, you can't pass the error info to the CF.  Is the error stuff stored in some undocumented register that the CF might be able to access, say DM[4001]? Oh that would just generate another run-time error....
• Yes, I know that the error info should be displayed on the 4x20 LCD. How does the CF "read" back what was written to the LCD by the PLC firmware?  

I believe that the only way to access this info is via a host link command.  I don't have enough spare serial ports on the FDM88-10 to allow me to wire the ports together. This way I could issue a host link command(s) to read the LCD display and get the strings spit out one serial port and sucked up by the other port.  

Could I achieve this by using issuing a host link command via Ethernet?

• If I could "read" back the error info can I write it to the extended file system to generate an error log?  How much of the PLC code can I expect to run from the run-time error interrupt handler?
• Is there anything that I can do from the real-time error interrupt handler other than to report the PLC?

On the dead-man timer mechanism.  Is there any way that I could log the events that led up to the timeout?  Or does the system just reset and start over?

Best regards,

Gary D*ickinson

I have coded myself into a corner and need some expert advice.

I am using the Fx1616-BA PLC firmware revision 91.1

My client's application uses 3 flow sensors with pulse outputs.  They are connected to PLC inputs 1,3 and 5.  I am using the the High Speed counters 1,2, and 3 to capture the total pulse count for each flow sensor.  Additionally I am using the pulse measurement system to measure either the PulsePeriod on the same 3 inputs.

The incoming pulse frequencies of interest are between 10 and 300 Hz.

For test I am driving the PLC inputs from the PLC's PWM outputs.  This allows me to simulate the behavior of the flow sensors without having to have a 15 HP pump and 460 volt 3 phase electrical service at my home.

I am having a problem with PulseFrequency(1) and PulsePeriod(1).  With a constant input signal at 50 Hz, if I call Pulse Frequency(1) every 100 ms the returned value will not always be 50 Hz, but periodically a value close to 30 Hz is returned.  The 30 Hz measurement shows up about every 20 or 30 measurements and the erroneous measurment lasts for a single call to PulseFrequency(1).

Now what makes this more interesting, is that the PulseFrequency(3) and PulseFrequency(5) measurements are always correct.  I can connect all of the pulse inputs to the same frequency source (remember I am using the PLC's PWM outputs) and only the PulseFrequency(1) values are randomly wrong.

The HSC mechanism calls an interrupt routine when the HSC reaches a programmed limit.  I have instrumented the interrupt routine and have found that with a constant frequency input, that the time between calls to the interrupt routine  is not consistent. This tracks the behaviors of PusleFrequency(1) and PulsePeriod(1).  HSC[2] and HSC[3] do not show these behaviors.

I have tried to duplicate the problem with a minimal PLC program, but have not been able to get a simple program to exhibit the failure.  

Let me tell you what else is going on with this PLC that may have some bearing on the issue and why I can't get a simple program to fail:
1. I am using one of the RS-485 ports to communicate with an external Modbus RTU device.  The Modbus traffic is fairly light.  I am sending out 3 Modbus queries every second, maximum.  Only a single registers is accessed for each query.

2. The RS-232 port is running the most traffic. It is connected to Weintek HMI panel.  The HMI is using the RS-232 link to access the PLC internals.

3. I have turned on the "High Speed Timer" mechanism for 1 TIMER.  I needed a timeout of less than 100 ms.

4. There are no DELAY statements or polling loops in the custom functions. Everything is written to execute as quickly as possible and to execute as seldom as possible.

Do you have any ideas as to what I did in some other life to get into this mess?

I am concerned that there might some sort of issue in your firmware with regards to the handling of the pulse measurement / HSC[1].  I worry about interrupts getting shut off for too long and edge events being missed. I am not having problems with HSC[2] and HSC[3] and that is both "good news" and oddly interesting.

Any suggestions on what to look for or to test for would be greatly appreciated.  If I could get this problem down to a simple PLC program, It would be in the mail.

As always, I am happy to work with you to figure this out,

Gary D*icknson

As many have noted the FMD/Fx ADC readings dance around a bit from sample to sample.  I have not been alone in observing this behavior.

The PLC's have some options for enabling a moving average filter within the ADC firmware.  And this helps with the noise.

I have been using a simple digital filter that acts as a low pass filter to reject the random noise and at the same time increase the resolution of the ADC channel from 12 to 13 bits (0..8191).

This is the simplest version of the code:

DM32[1] = ((DM32[1] * 31)  + ADC(1) + ADC(1)) / 32
[/font][/color]

How do I use it?  I invoke this code 10 times every second usually timed to the Clk:0.1Sec signal.  My actual application only needs to look at the computed ADC value once every second or two.  I'm not working with stuff that changes all that rapidly.

How does it work? This is a simple single pole IIR (Infinite Impulse Response) low pass filter.  Each time the code is called the output, calculated output value, DM32[1] is updated. The new output value is 31/32 of the previous value with the "new" ADC value contributing only 1/32 of the "new" output value.  This is a digital implementation of an analog filter that might consist of a series resistor and a capacitor to ground.  Google "IIR low pass filter" for the real science.

Why do I add the ADC(1) value into the equation twice? I wanted to double the resolution of the ADC from 12 bits to 13 bits as a byproduct of over ADC over sampling. I found that if I use two separate ADC samples that this works much better.  There is actually a requirement for a bit of noise from the ADC conversion to make the oversampling work. Google ADC oversampling for the technical details.

Ok what is the down side of this trick?  Response time.  If the input makes a big change in value, the output, DM32[1] will take a few seconds to respond to the change.  The two constants 31 and 32 in combination with the sampling rate (0.1 Hz) determine the time constant for this filter.  If the filter is too sluggish for your requirements, increase the sampling rate or change the filter constants to 15/16 or 7/8.

I have been working, with systems that the analog values cannot change very rapidly.  One of my clients monitors the levels in 100,000 liter fuel tanks using a pressure gauge.  It takes over 2 hours to fill the tank and about a week to empty into transit buses.  So from one second to the next the level in the tank cannot change so the filter delay is insignificant in this application.

So I am happy to trade off some response time to get stable ADC readings and double the resolution of the ADC from 12 to 13 bits.


Best regards,

Gary D*ickinson

I may be losing my mind, but I can't get FileZilla 3.11.0.2 to work with the Fx and FMD PLCs.

I've had older FileZilla versions work, but now when FilleZilla sends the "LIST" command to the PLC's FTP server, there is no response from the PLC and the command times out.

I can "talk" to the PLC using Windows command-line version of FTP. This works fine to send/receive files and list out the files on the PLC. So I know that the problem is not with the PLCs nor my marginal understanding of FTP.

Do you have a recommendation on a Windows based FTP client that still works with the PLC's.

The reason I bring this up, is that you have used FileZilla as sort of a standard FTP client for use with both the PLC web-server and the PLC's filesystem and FTP fileserver documentation.  And right now I can't get it to work...

Gary D.

Sorry, but I broke the simulator in i_TRILOGI 7.03 Build 08.

I was working with the PidCompute function and got real different results between hardware and simulation.

This is the entire program:


PIDDef 1, 1.0, 0.333, 0.0, 0.0      ' chn, limit, P, I, D ...

A# = PIDCompute(1, 1.0)         ' A# will be 0.333 with simulator. 0.0 with hardware
[/font][/color]

Target hardware Fx-CPU F90.7

I think that the problem is with the PLC firmware and not the simulator. The issue may be setting the limits argument to PIDDef to a value of 1.  I was expecting the values returned from PIDCompute in the range of -1.000 to +1.000 but only got values of 0.0!

If I program everything using scaled arguments limit = 1000, P = 333.0 the the output from PID compute is 333. I suspect that something in the "new" PIDCompute function was not completely recoded for floating point calculations.

Is there a never version of firmware for the Fx processors?


Gary D.