Want to share a UDFB? Here's the place! NOTE: This page contains files and links to items developed by third parties. Unitronics bears no responsibility for any consequences of accessing and using any third-party items of any kind.
Main PLC has to read servo's encoders in order to 'know' current location of device. In the worst case that some instructions (currently send via modbus) like displayed buttons won't execute then reprogram buttons to physical output module instead of relying on modbus.
"I use the Modbus portion to set parameters in the servo" - either do I, " before I trigger a move with a voltage signal or contact." - currently I send it via modbus but yes, worth to think it over.
I suspect the thread is not as the servo driver would like.
That is why I modified the theart parameters and the read again and I do not have any answer. I do not have any possibility to watch the thread to verify the communication.
I will try to build the protocol that could make me sure that the thread is good.
I feel the need to add something to Denis's comment "if you need address 1, 5 and 7 on the device, it is better to read 1 and set a length of 7 than to try to read using 3 separate reads."
On many devices I use, this is not possible. If the device itself doesn't have any knowledge or use of any register involved in the vector, it will often return an error. Many, many times I have to do separate reads on a single device to get all the info I need because of this quirk. It is a complete PITA, as the makers often spread the "most relevant to what the sensor does" registers many numbers apart, with gaps in b/n. Air sensors with temp at 013, Hum at 121, CO² at 217 ....... instead of all 3 in registers 2, 3 & 4; with the rest of the useless to the user garbage that they use internally but for some reason have them as register usage, placed everywhere else but often with number gaps. You get the idea. I'd really like to give the people who make the devices a big smack on the bottom and then send them to the dunce corner for the day. With NO coffee or chocolate allowed at all for the rest of the month.
The vector method is certainly much faster, but you can only do it after initial testing using the PC to see if it is "actually" possible.
You can scan barcode by Protocol FB. Scanned barcode is replaced by another one in buffer if you try to scan another barcode.
There is several options in this process:
1) Barcode 1 = Barcode 2. User can scan barcode 1 (or barcode 2) two times and it is wrong solution.
2) Barcode 1 not equal Barcode 2 but these two barcodes is an assembly unit - you can scan it and find a row in DTI where another one barcode is present.
3) Use two barcode scanner with different positions (stationary) connected to different com ports. Parts scanned if it fit correctly.
4) Barcode 1 + Barcode2 = constant. Scan barcode1 add to SUM tag, scan barcode 2 add to SUM tag and compare with CORRECT SUM tag. Reset SUM.
5) Generate different sound for different barcode (zebra motorola barcode scanner has this option embedded into firmware).
I implemented barcode scanner for wire harness checking device.
The main problem - user scan barcode - check wire harness ---OK. Then user scan barcode for another one but did not check another wire. The first OK wire harness is checked many times.
In system log all wire is checked but it is not correct.
After all we used hardware for marking good wire harness and if marking is present - user cannot check one wire many times.
This problem is the main in your system. User can scan correct part many times and use wrong one in assembly.