Internet PLC Forum

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 haven't learned how to use the built in coils for: counters, sequencers, timers, except for the Clk: ones that I'm using. I will learn what I need to, if I need to, but at the moment it appears that splitting up the actions into 5 different seconds of a 5 second cycle is doing the trick. Although, I'm not done writing the program, so I'm not out of the woods yet.
I would have to look more closely, but I don't think any of my functions can be skipped if one function takes too long to execute, so using an interrupt just moves the problem around.
My flow meters (and at this time all my sensors) are 4-20mA analog signal. I think this allows me to avoid leaning Pulse-* commands for now, as I can't use them with the sensors that are already bought.
However, I'm trying to read the output every 5 seconds and apply the observed flow rate to the previous 5 seconds to compute volume. If the PLC falls behind real time then I'm not calculating the flow volume correctly anymore. At that point it's better to go to a 10-second cycle giving each of the 5 parts 2 seconds to run, or have 10 parts at 1 ssecond each.
I think it's time to write a piece of code that compares the number of cycles to the number expected over a longer period of time. The weekend is coming up, a perfect time to test!

General questions about efficient coding:

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

If I have many "IF" statements that are normally false (testing for problems) do these statements get processed very fast?
The idea is to build a nested structure with the least likely "TRUE" test at the top, so that the least amount of the nested structure gets analyzed at any pass through. The downfall is that this will take more lines of code because I will have fewer nested IFs within each IF statement.
 (I should have paid more attention in school when they talked about efficent coding practices.    )

My code is only 2000 lines so far, and I think the biggest limitation is reading over the RS485. If I find I still have problems with inefficient code I'll ask more questions about how to streamline what I'm trying to do. Thanks for all the help!

Hi Gary, thanks for the response.
We are automating an irrigation system. The tank levels don't change quickly, but the flow sensors do. We are using flow sensors that output flow rate, and applying that rate over time to get flow volume. On the one hand we would like to scan the rate very often to capture abrupt changes in flow that occur when a valve opens and pipes fill, on the other hand converting rate to volume leads to a "rounding" error every time you do it so doing it less often reduces the rounding error. I guess if I'm taxing the PLC then that is another reason to scan less often.
I can convert the HMI to ladder logic, and I can implement your RETRY code for the 7017. You have suggested to stagger the 7017 readings. One way I can think to do this is to run the Clk1.0s and use a counter with an IF statement to run each one on a different second. In fact, I can split up the reading of all the other sensors too, so only 1/5th of the code runs per second. Is there a better way you can think of doing this?

In your description of the ADCError you say you, "do not want my PLC to lock up polling dead hardware." Do you mean waste time, or is it possible that the PLC will become unresponsive and stuck? Also, if that relay is tripped does your program stop trying to read from the 7017 for all future scans?

I have a Clk:1.0s that runs every time and others that run when in a particular State. Is it better for these to be on separate ladder rungs? I could combine them into one rung with TestIO for which state is active if that would avoid problems.

I'm hopping support will answer my question of what happens with multiple rungs of Clk:1.0s when the functions take longer than 1.0s to complete. Is the lower rung just skipped? Or does the program as a whole stop running in real-time while waiting for functions to finish? Or are certain rungs skipped depending on what time it is when an above rung completes the function? Any one of these will cause problems in the code I have, but if I know which one I can change the code to avoid problems.

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

That did it, Thanks!
I was thinking that the 10 pin connector marked "Reserved" in the F1616 manual was "reserved" for the keypad. Clearly I was wrong.

Thanks for all the help support. It really makes a difference for someone like me just getting started working with all these new products.

I'm working with JR on this project so I'm going to continue a line of questioning in this thread.

We will be using the I-7017 at more than 10ft away from the PLC, so we will need the pull up resistor set-up. For the RS485 line power I see we need 9V, and I believe that can be 5-9V. I have my F1616 Analog ports connected to a AN20MA-2, so I've given up my 5V voltage source from the analog port. I think my next best option is to purchase a transformer to power the I-7017. I will have three of these I-7017 multi-dropped at different locations.
---What is the current requirement of the pull-up resistor set-up?

For this set-up I will also need resistors. The resistance I need is shown on the diagram, but my local electronics parts store also asks what wattage the resistor needs to be. I've tried to figure this out, but related to the above question, I don't know what currents I'll be dealing with.
---What wattage resistors do I need, or should I just buy them all at 1W to be safe?

I followed the TRi manual for connecting to an I-7017 using the U-485 USB to RS485 to connect to the PLC. The directions in the TRi manual can't be followed because the I-7017 website has since been updated. I downloaded DCON Utility, but the utility window looks nothing like the sample image in the TRi manual. I was able to connect, but I wasn't able to change the ID of the I-7017.
---Will you please update the TRi manual for the I-7017. At the moment I'm most interested in how works with the F1616, but foresee needing to use it with an FMD88 or other PLC from TRi.

Thanks!

I am using an FMD series PLC to read a pressure sensor. In order to get the number of significant digits I need for accuracy, I have to use very large numbers (1,000,000.) My proceedure works when using "letter variables" but not when using DM[] variables. I thought there might be a limit to the number of significant digits for a DM[] variable, but I can't find any mention of this, so now I'm confused.

Sample:
'---Read Main Tank water level
A = ADC(1)       'Tank sensor raw output
DM[11] = ADC(1)
'Calibrate the reading
'These sensors output values on the order of 1000 / foot,
' so to get acuracy of 1/10th of a foot we need to convert to
' 1/1,000,000 to calibrate, then convert back to 1/100th of a
' foot before moving on in the program
B = 2658             'Slope (1/1,000,000 feet)
DM[12] = 2658
C = -2120000             'Intercept (1/1,000,000 feet)
DM[13] = -2120000
D = B * A + C     'Calibrated water level (1/1,000,000 feet)
DM[14] = DM[12] * DM[11] + DM[13]
'Convert back to 1/100th using MOD to trim unwanted sig.dig.
DM[100] = (D-(D MOD 10000))/10000
DM[101] = (DM[14]-(DM[14] MOD 10000))/10000
DM[102] = ((DM[12] * DM[11] + DM[13])-((DM[12] * DM[11] + DM[13]) MOD 10000))/10000
D = DM[100]       'Calibrated water level (1/100 feet)

"D" gives me the correct value, DM[101] doesn't get calculated, and DM[102] returns an incorrect value. (They should all be equal.)
Do DM[] variables keep fewer significant digits that "A, B, C" type variables?