Internet PLC Forum

I have a program that runs alright in the simulator, but not on the PLC(F1616-BA). I have 5 functions which run on the CLK:1.0s every time, State independent. There are some loops in there and a reading of 3x I-7017 over RS485. I also run an adaptation of the HMI sample code which runs every CLK:0.1 when State 1 is active.

One problem is that I'm not getting any reading from the I-7017s, even with a few sensors attached which work when the PLC is running the (much smaller) I-7017 sample code altered to read three 7017s at a time.
I also find that the HMI keystrokes require an unnaturally long depression of the key before they register, and then stay registered for a moment.

I was trying to think how I could have taken working code and corrupted it during cut/paste when I noticed that a variable which should increment every 0.1sec (off CLK:0.1s), was in reality incrementing much slower than that. After 60 seconds in real time, the counter represented 11 seconds. This makes me wonder if my code is causing the PLC to be in mid-execution of some part of a function when the CLK:1.0s forces it to go elsewhere. Or, just as bad, that the PLC continues what it's doing and ignores the request from the CLK:1.0s.

Can you please help me narrow down the possibilities?

Edit: improve clarity and spelling

Travis you have to be very careful with the coding of custom functions to ensure that they execute very quickly becuase the ladder logic scanning mechanism can not proceed until the function completes.

I didn't like the sample HMI code because of the polling of the keyboard I/O every 0.1s.  My version uses ladder logic to detect if a single key is pressed, and then and only then invokes a custom function.  Why waste time in a custom function when there is no key pressed, therefore there can't be anything to do.  

The the PLC comunicates with the I-7017 over RS-485 and the NETCMD$() function has to wait for the serial mesage to be transmitted to the I-7017, then processed by the I-7017 and then wait for a message to be send by the I-7017.  This whole process could easily take 100ms.  If you are talking to 3 I-7017s on the same scan your could be tying up the PLC for close to a 1/4 second every second!

I'd suggest that you poll I-7017 at the lowest rate that that makes sense.  Do any of your analog inputs change much in 1 second or 10 seconds or 100 seconds?  I worked with an 400 gallon aquarium that took about an hour to change 1 degree C with the heaters running full blast.  There is no point in checking it's temperature once a second.  I checked it once every minute and that was serious overkill.

For sake of arugument, lets say that you could safely poll your I-7017 once every 10 seconds.  Poll the first one at 10 seconds, the second one at 11 seconds, the third one at 12 seconds...

The following is the code that I use for a single I-7017.  The code is a little more complicated than the example code.  This code is much more robust that the example code and provides methods to allow the PLC to continue to function even if the I-7017 dies.

The Simulation RELAY is checked to see if I am running the code in simulation vs. real hardware.  The simulator doesn't simulate NETCMD$().  The ADCError is a RELAY that is set if the I-7017 quits responding or has not been successfully initiated.  I do not want my PLC to lock up polling dead hardware.  

I have a retry mechanism that will wait and resend the NETCMD$().  I found that this improved the reliability of the system tremendously.  I kept track of how many retries were required and it was less than 1 every week on my system.  The retry was much better than having the system fail once a week.

The for next loop at the end of the code extracts the ADC value for each channel and then scales it to enginerring values that are easier to read.  It's easy, even for my old brain, to read 370 and think that means 37.0 C. The scaling components are stored as a set of 3 integer values in DM.

Writing to the LCD was done on the next ladder scan.



' ReadAllADC - function to read, scale and format all 8 analog value from I-7000
'
IF (TestIO(Simulation) = 0) AND (TestIO(ADCError) = 0)
' Read all available ADCs from a I-7000 device
' NETCMD$ is used to send command and wait for response
' using the suffix "~" to suppress the FCS computation

???I = 4???' Retry count
???W$ = NETCMD$(3,"#01"+CHR$(13)+"~")
???WHILE (LEN(W$)= 0) OR (ASC(W$,1)<> 62)
???I = I - 1
???IF (I = 0)
???SetIO ADCError : RETURN???' Still not working
???ENDIF

  '   Retry command
'
???DELAY 10
???W$ = NETCMD$(3,"#01"+CHR$(13)+"~")  
???ENDWHILE

' Extract all numerical digits from the response but omit the
' decimal point. Each data fragment is represented as a percent of
' the A/D fullscale (+100.00 to -100.00). Full scale input is 250mV.
' "+xxx.yy" or "-xxx.yy".
' Extracted integer integer data will be returned in DM[201] to DM[208]

???FOR I = 0 to 7
  ???T = VAL(MID$(W$,2+I*7,4)+MID$(W$,7+I*7,2))  ' Get the digits w/o the period

' Scale the data to engineering units
'
???T = T * DM[41+I*3]
???IF (DM[42+I*3])
???T = T / DM[42+I*3]
???ENDIF
???T = T + DM[43+I*3]
   ???DM[201+I] = T???' Store Scaled result for this channel
???NEXT

ENDIF


[/color]

Gary D

Running the HMI I/O as direct ladder rungs works great. No more lag in keystroke pickup.

After splitting up the code so that some things run on the first second of a 5-second cycle, and some on the 2nd second, 3rd second, etc. I was still not getting a read on the 7017s. I noticed one line of code in the sample code for the 7017 that I hadn't given much thought to. The first line of function 250 is "SetBaud" Comm 3 to 9600, which is what the 7017s are expecting. The default Baud rate for the RS232 and RS485 is 38400 for this PLC so adding this line to the 1st.Scan function is needed to properly communicate with the 7017s.

Is it likely that increasing the Baud Rate would allow me to go back to my original code where everything runs every second?

Travis,

In response to your question about approaches to make delayed clocks.  I've included another version of code that I have used in one of my PLC projects.

This version uses only a single COUNTER, but using the Sequencer mechanism that is available only to the first 8 counters in the PLC.  The other version used a RELAY for each state and chews up more of the PLC resources.

This version divides the incoming clock by 5.  Each output runs at 1/5 the input clock rate and each output is delayed in phase from each other by one input clock.

If you want a one second output clock, run this circuit from the 0.1sec contact and change the Set Value of Seq1 to 9 (divide by 10).


Gary D.

Regarding flow rate and flow volume

What kind of output does your flow rate sensor produce? If your flow rate sensor produces a train of pulses and if you are using a Nano-10, FMD or F-series PLC you can feed the pulses to a High speed counter (HSCDEF) input channel which also simultaneously support PULSEFREQUENCY or PULSEPERIOD functions. This way you can obtain the instantaneous flow rate data using the frequency or period of incoming pulses and AT THE SAME TIME you get cumulative pulse counts from the HSCPV counter which gives you the total flow volume.

 Is it better to us "AND-OR" or to nest the IF statements?

The fastest execution is in resolving the ladder logic (series or parallel rung). TBASIC statements takes longer to run. AND-OR might be quicker than nested IF statements.

However, generally statement execution time is seldom a problem unless you are filling up large amount of data memory or FRAM. Delay due to failed communication via RS232 or RS485 is a much bigger issue. When communicating with other devices the CPU need to send the command and wait for a response. The transmission time is determined by the baud rate. The device it communicates with may need some time to respond and during this time the CPU can only wait until it receives a proper response, or time out (default is 0.15s) if no response is received. The NETCMD$ by default retries two more times if it didn't receive a response. That means if the device fails to respond the CPU will waste 0.45s not getting anything else done. (You can change the number of retries and waiting time using the SETSYSTEM command)

So it is important that you test the communication routine first to make sure that you work out all the bugs in the communication code so that there is little delay in communication when the partnering device is active and have a mechanism to detect failure (as per Gary's suggestion) when the partnering device is not responding so that it does not become a drag on the total system performance.

To use your 4-20mA flow sensor to accurately compute the flow volume, you could setup a periodic interrupt to run a custom function every 5 seconds (5000 ms), read the analog input and compute the flow volume in the last 5 seconds and add to a variable that stores the cumulative volume. That should give you a very accurate flow volume readings regardless of execution time of the rest of the program.

Note: Periodic timer interrupt is not available to M-series PLCs. Nano-10, FMD and F-series PLCs all support the periodic timer interrupt.

Well, it didn't take long for the problem to be noticable. I set a counter which would increment within one of the functions  every 5 seconds. After about 30min it was more than 60 counts BEHIND what it should have been. Back to the drawing board.

I have 18 flow sensors, so some are being read off the PLC (via AN20MA-2) and the rest off the 7017s, one of which is co-located with the PLC and the other two are some distance away on a different part of the property.
Communication with each 7017 happens during a different second, but other custom functions run during the same seconds as the 7017 communication. I've tried to space things out evenly, but it clearly isn't working at the moment.
I'm open to suggestions, including different PLC equipment or communication protocols. One thought I had: use an FMD88 to replace the 7017s. I could multidrop them just the same, but do some remote calculations and send the calibrated data, thus processing remotely and freeing up some processing space on the main F1616-BA.
Ideally I would handle the problem through more efficient code, but if it means scanning the sensors much less often then I want to have an alternate option for the client, one which would allow the high scan rate we originally discussed.

And in case I sound unappreciative, I want to once again thank support and Gary for all the help with this project. It?s been fun learning all this stuff and I'm considering automating and datalogging my own apartment!

Geeze , just ran another 30min test and this time the counter is where it should be, implying no lag. I'll let it run over the weekend and see how it does.