Program execution takes longer than Clk:1.0 Clock?

[garysdickinson]

The periodic interrupt approach is an excellent mechanism for polling the I-7017s.  

Once again if your code wastes time waiting for the response from the i7017, the ladder logic bits may run slow.  If you use the periodic interrupt mechanism you should also use it to keep track of "time" by incrementing a variable on each call to the interrupt routine.

The use of the Netcmd$ function is convenient, but it ties up the PLC until the I-7017 responds.  If you find that this is where the time is spent (and this messes up the PLC behavior), then you can build your own version, a non-blocking version, that does not tie up the PLC.

A "non blocking" version of netcmd$, requires two or more special functions and some ladder logic.  

The first special function sends the request to the I-7017 and then sets a RELAY to indicate that a response is expected. This function will be very fast and will exit probably before the first character is transmitted.

Using ladder logic you will start a timer that will run for about 100ms and the invoke the second custom function.  The assumption is that 100ms is long enough for the Plc to send the request, the I7017 to process the request, the I7017 to transmitt the response and for the Plc to accept the transmitted response.  

The second function parses the response.  It does not wait for a response, the response data will already be available. Note that I have not even mentioned a retry mechanism, you'll probably need one.

This is pretty complicated stuff but it allows the PLC to be very responsive because your special function code is never wasting time waiting serial data to be sent or waiting for a response from the i7017.  The ladder logic will not miss fast clocks and will remain responsive to inputs.

[Bruceh]

Hi Guys,
Very interesting discussion and some great suggestions regarding how to set up robust code to cope with communications that don't always behave nicely and on time.

My comment is to also consider that so long as you get a reading from your sensor and you are keeping track of time then you can calculate your volume. You dont actually need a reading every 5.00 sec but you do need to know the time elapsed between readings and the flow that has occured during that time

 If the flow fluctuates a lot then you need higher resolution sampling by increasing the sampling rate to approach a better approximation but as has been pointed out your flow meter is likely to be +/- 5% anyway.
Regards,
Bruce

[TravisB]

I was considering switching over to the method that you describe. The way it worked out it my head was going to use more DM fields (which means writing to memory) and more lines of code. The result, I think, is even slower code execution.

As an update to my weekend test, after ~2.5 days I found my counter was 0.08% behind what it should have been if it executed successfully every 5 seconds. This wasn't a robust test, but it does show that the problem is small. If I consider that each flow sensor only has flow 1/2hour of each day, my end of year total error looks to be 0.25% We have decided to ignore the error for now, and I'm keeping my fingers crossed that the problem is in fact as small as my little test makes it seem.

[garysdickinson]

Travis,

Excelent bit of sicence to get a handle on the magnitude of the problem.

A 0.25% error is very small!  If you look up the specs for a nice Fluke DVM, say the model 179 that retails for almost $400 you'll find that its only a 1% meter when measuring 60 Hz AC voltage!  With DC voltage its spec'd at 0.09% + 2 counts.

I agree with your decision to stay with simple code!

Gary D

[TravisB]

The equipment has moved out of the lab and into the field. Everything is wired up and it appears that I'm failing to communicate with the 7017s more often than not.

One 7017 is adjacent to the PLC, one is about 50ft away, and one is +100ft away. The two furthest 7017s have biasing and pull-up resistors installed.

I got rid of the part of the code which, after complete failure to connect to a 7017, it would stop trying on later cycles. The result is that I /sometimes/ get successful connection and sometimes fail. I added an "attempt" counter and a "failed" counter to calculate the success rate, so I'll have that statistic next time I make it on-site.

Elsewhere in Tech Support it was suggested to use the U-485 to watch the RS485 communication as it's happening. I have purchased a U-485, loaded the driver and my computer is recognizing it. I also loaded up the Realterm SourceForge terminal software I saw suggested elsewhere in TechSupport http://realterm.sourceforge.net/. From reading the SourceForge website, I think I want to "Spy" the communication. When I try that in the office (nothing wired up) I get a pop-up demanding a donation ($20) before I can use this option. Is this the option I need, or should I use "Monitor"?

Once on site, I will wire up the U-485 as shown here: http://www.tri-plc.com/drivers/U485-Drivers2009forCP2102/CP210xSetupGuide(English).pdf on page 3. (I wont be using the 120Ohm resistors.) What isn't shown is the relative location of the PLC. If I have occasional success communicating, can I wire the U485 directly to the COMM port on the PLC (without resistor) to do the spying? Aren't the needed resistors and pull-up stuff already there for comm with the plc?

So, assuming I make it that far, what next?
If I need to use "Spy" then I click the "Ports" tab, set the Baud to 9600 (default for PLC and what my 7017s are set for) and make sure the port is set to match the location of the U485. There are many other options to select at this tab and I don't know what the rest of it means, so if there is more to do, please let me know. At some point I'll click the "Spy" button and, if I've made my donation, /something/ will happen. What will happen? and what does it tell me?

My plan is to go on site as soon as I have a clear plan of troubleshooting. Right now I'm unclear on how to use the U485 to troubleshoot.

[support]

Are the I-7017s and the PLC sharing the same power supply? If not did you connect their 0V together (it could be to the shield of the twisted pair cable)?

At 50 ft and 100 ft you shouldn't have so much difficulties communicating unless there is a setup or programming problem or there is a big noisy equipment that is coupling high energy noise pulses on the RS485 wire. Did you use a twisted pair wire?

Since you have a U-485, you could take the PLC offline first and then use the software tools supplied by ICP-DAS to monitor the I-7017s on a PC and check if you have any difficulties communicating with the I-7017s.

If PC communicates well with the I-7017 then you can connect the PLC to the RS485 port (quit the ICP DAS software since you don't want the PC to interfere with the communication between the PLC and the I-7017s.

Also are you sending ASCII commands back to back to multiple I-7017? Try putting a small delay between two consecutive commands as the I-7017. You can try it with 1 second delay and see if it improves the response and if it does then slowly decrease the delay between two commands until you reached minimum delay necessary between two consecutive commands in order not to have disruption.

Regarding Realterm software - note that this is not our product and we only recommend it because some users have good experience with it, but we won't know their donation policy and we can't guarantee its performance in doing their job.

[TravisB]

Are the I-7017s and the PLC sharing the same power supply? If not did you connect their 0V together (it could be to the shield of the twisted pair cable)?

--No, the I-7017s are using different power supply units, same brand and model though. I hope we have an extra wire available for connecting the 0Vs. So on the AnalogGnd from the PLC (via AN20MA) to the (B)GND 10 on the I-7017.

At 50 ft and 100 ft you shouldn't have so much difficulties communicating unless there is a setup or programming problem or there is a big noisy equipment that is coupling high energy noise pulses on the RS485 wire. Did you use a twisted pair wire?

--I will verify this.

Since you have a U-485, you could take the PLC offline first and then use the software tools supplied by ICP-DAS to monitor the I-7017s on a PC and check if you have any difficulties communicating with the I-7017s.

--If connecting the common ground doesn't work, I'll move onto this step. Is it the DCON Utility (http://ftp.icpdas.com/pub/cd/8000cd/napdos/driver/dcon_utility/) that I want? (Here we go again with trying to learn new software to troubleshoot equipment that's installed in the field. )

If PC communicates well with the I-7017 then you can connect the PLC to the RS485 port (quit the ICP DAS software since you don't want the PC to interfere with the communication between the PLC and the I-7017s.

Also are you sending ASCII commands back to back to multiple I-7017? Try putting a small delay between two consecutive commands as the I-7017. You can try it with 1 second delay and see if it improves the response and if it does then slowly decrease the delay between two commands until you reached minimum delay necessary between two consecutive commands in order not to have disruption.

--I have a 5 second cycle with each 7017 being called on a different second (2, 3, and 4) resulting in less than a full second separation between calling. I can rework the program to add a longer delay if nothing else works.

Regarding Realterm software - note that this is not our product and we only recommend it because some users have good experience with it, but we won't know their donation policy and we can't guarantee its performance in doing their job.

--I understand this is not your product. Maybe someone who has used it with success can help out here.

[TravisB]

Success from the field. The pull-up resistors are being powered by the DAC#4 of the AN20MA-2. The AN20MA wasn't wired to 24V power supply, so it wasn't getting power to the DACs. Once that mistake was discovered the 7017s were having 100% success rate of connection for the few hours it was being monitored.
Trouble-shooting rule #3, Check the wiring before blaming the "black box."

[support]

Good to know. Thank you for sharing the info and we are glad you got this resolved.