Flex727

Here is a list of issues that I noticed at a glance (the first 3 items are just about best programming practice - they won't prevent your code from working): Rung 1 - Use the Power up with the operand instead of SB 2. Rungs 7-10 - ALWAYS use a transition contact to load an HMI display (I recognize that your code would have the power flow on for only 1 PLC cycle, which is why it works). Also, don't add any code in the same ladder rung after an HMI call FB. Rung 11 - Just use SB 2 for all your comm initializations. I'm finding it surprising that your tap machine (or whatever the MODBUS slave is) takes that much longer than the PLC to boot up, but if so, then I suppose you have to do it the way you are. However, use SB 2 to initialize everything, then place your delay on the connect only. The PLC doesn't care, but it's better programming practice. Rungs 19-22 - You need to SET a bit for your read and write, then RESET the bit at the end of the MODBUS read & write (similar to what you correctly do for the connect & close functions) to allow for the busy bit to be on. This may be why you were seeing unpredictable results without the timers.

Just a quick glance and I see that you have your analog input as the output of a linearization FB in rung 10 of the linearization subroutine. That will not work. You have a lot math in rungs 8 & 9 that makes little sense to me. Until you get the motor running the way you want, simplify everything to a direct input of the RPM on the HMI screen with a readout of the RPM from the analog input visible on the screen. Also, be sure you are using 3277-16383 for that 4-20mA analog input, not 0-16383.

Assuming the largest available font won't work for you, find or create 10 images for the digits 0 - 9 that are the size you want and use the "List of Images: By Pointer" HMI element.

I've been doing this for many many years and can't remember the last time I needed floating point numbers in my program except for some crazy flowmeters that insisted on outputting their data via MODBUS as floating point. Insane, if you ask me. I guess if you have a situation where the number of significant figures in the decimal varies and is unknown at the time of programming then floating point is necessary. Other than that it's poor programming practice in my humble opinion.

Almost never. Multiply by 100 or 1000 (or whatever precision you need) in your linearization function block and then keep track of the location of the decimal point through any subsequent calculations. The HMI display function for integers has a handy virtual decimal point that you can use for display. I spend most of my time with VisiLogic rather than UniLogic, but my recollection is that the 16-bit integer registers are signed (VisiLogic has both signed and unsigned 32-bit registers, and only signed 16-bit registers - I think UniLogic is the same). Just use negative numbers as you normally would. Just be careful about register overflow and divide by zero. It seems I'm always dealing with converting flow rates to volume (most of the time) and volume measurements to flow rate (less often). Either many system designers don't understand that they need to use the proper sensor for the job at hand or they just go with whatever is cheaper at the moment (sometimes you need both flow and volume so conversion is necessary regardless). Converting between those two domains is very cumbersome and elegant solutions are rare. For converting flow to volume, you need to integrate. I just time slice the flow (usually in 100ms increments) and sum (there is some additional math involved to get the units correct). For the reverse, you just have to measure the volume as often as you can, calculate the time interval and filter as heavily as needed to get something approximately matching reality. If there's a better way, I sure would like to hear it.

Everyone should know about this feature and use it.

Very nice, @John_R! This is the best answer, IMO.

@Ausman is correct - you need a hub, not a switch (I misread @Joe Tauser's post), which I don't have. However, I did some other experiments. I increment a DW on every scan and divided the R/W Mix Acknowledgements count by the scan count. The result seemed to vary a bit from startup, ranging from 82% to 97%, but mostly hung around 95-96% and was remarkably stable there. The PLCs connect through a switch, along with my desktop PC. The rest of my network is wifi through a router and so the PLC network is independent of other devices. The scan time of the Master PLC (V1210) is 7ms and the Slave PLC (V700) is 3ms. Since these are nice prime numbers, I expected to see a lot of aliasing to cause dropped packets, but that doesn't seem to be the case. With very consistent >95% communications success rate on every scan, I'd say the Unitronics PLC is indeed completing the entire MODBUS R/W Mix function in a single scan. I could see no effect even when online with the PLC using Ethernet (on a different Port & Socket, of course). Many of my projects that involve MODBUS TCP communications are on an isolated network. When that is the case I plan to always execute the comm FB on every scan rather than try to run a timer to slow it down. It makes the Slave PLC as responsive (to button presses, etc) as being at the Master. I wish I had realized that you could communicate on every scan years ago.

MBs are bits. Use them.

You may be able to use the "Toggle Register Bit" function under the "Logic" ladder menu for this purpose. What are you trying to do? Typically in VisiLogic, bit vectors are employed to do this rather than trying to manipulate the bits in an integer register.

Moved to correct forum.

To utilize what? Yes, you can always store data to the SD card and physically retrieve the card to access the data.

I have Wireshark and an Ethernet switch. When I get a few moments I'm going to try that.

I just completed a project and noticed something odd. The project is as follows: Chemical blender controlled by a V1210 PLC. This machine blends 4 different chemicals to the customer's specification into 4 different tanks (each with a different mix of the 4 chemicals). The chemical flow is controlled by 4 Entegris flow controller/flow meters (analog I/O). A remote panel (V700) is located 50ft. (of Ethernet cable) away. This remote panel can control the operation identical to the main panel. Blending and tank filling can be started or stopped at either location. Communication between the two PLCs is by MODBUS TCP with the V1210 as the Master and the V700 as the Slave. Since all blending operation and control occurs at the main (V1210) panel, but operation of the system will generally occur at the remote (V700) panel, I wanted the best user experience I could obtain at the remote panel. If you've ever had remote control via MODBUS, you've noticed that there can be a bit of a lag to get a button response on the HMI screen (i.e. you usually have to hold the button down for a short time to get it picked up by the MODBUS polling). I usually run polling by either a timer or use SB 15 (100ms transition). The shortest timer possible is 10ms, which improved things considerably, but I checked the scan time on the V1210 and saw it was between 6 & 7 ms, which might improve things further. I was using the Unitronics R/W MIX FB to transfer data and hung that directly on the left rail (with SB 150 and the "function in progress" bit, but no timer). This caused the data transfer on every scan and dramatically improved the user interface at the remote panel. It was nearly as responsive as the main panel. Checking the TXD / RXD counters, there were no dropped packets at all - very good result, and I'm quite happy. However, I did notice a minor oddity. Also on every scan, I am performing the necessary integration of the flow rate to total volume and display it on the screen. My normal method of integration in this type of circumstance is to time slice the rate using SB15, perform the necessary math to convert mL/min to mL/100ms, then sum to obtain total mL. On the main panel where all the calculations are performed you can see the flow rate is constant and the total volume increments up very smoothly. However, on the remote panel where that number is transferred over on every PLC scan (of the V1210), the total volume does not increase smoothly. It has a halting appearance, not smooth at all, that totally mystified me for awhile. I think I now know why (though I could be wrong). Anyone want to take a stab at solving this mystery?

I'll PM you.