TimothyMoulder
Member
This isn't a question, it's to share what I've discovered so that the next poor sap who attempts this will be able to avoid some of the pitfalls I've climbed out of...
The hardware :
Unitronics Vision 280 with ethernet option.
Make SURE you have the latest firmware - the modbus IP slave address of 255 no longer applies, and can be disregarded IF you have the latest firmware. Note, you do not get the latest frimware when you download Visilogic, it has to be done separately from within Visilogic using the Check for Updates function.
The Software :
Plantmetrics from Rockwell Automation
Configuration is pretty straightforward, but watch out for the bug described here :
http://www.plctalk.net/qanda/showthread.php?s=&threadid=10630
When assigning addresses to data points in Plantmetrics, use Matrikon aliases at you own risk. I couldn't get them to work, but I might have been making configuration mistakes.
Matrikon OPC Server for Modbus (plant based edition) from Matrikon Software
This software has it's own set of problems. Most critically, it doesn't poll PLCs once it loses contact with them, like RSLinx does (nod to Ken and company). When you lose a node in Linx, it looks for the node until it finds it or you tell it to stop by removing the node from the configuration. Not so, Matrikon.
If the machine is powered down, data collection stops (obviously). When the machine is powered up again, and the ethernet card is reinitialized, Matrikon takes notice and begins polling again.
If, on the other hand, you reboot the computer hosting the Matrikon software, and it comes up while the machine is running IT WILL NOT GO LOOKING FOR THE MACHINE! It sits there staring into space, waiting for the machine to yell, "Hey, dumba$$, over here!"
Now, to Matrikon's credit, it seems they've attempted to fix this problem with the "Check Connection" box on the TCP driver. Watching it's behavior, it seems to be polling every 5 seconds for a particular memory address to see if the PLC is out there someplace.
However, I cannot confirm this as yet, since the address the Matrikon software is looking for is not implemented in the V280 controller from Unitronics mddr So the box serves no purpose here.
Ah, but happy day, I have a work-around. In the V280 is a register
SDW 20, which is the default modbus register for sessions (packets) received. This will not increment unless actively scanned by the Matrikon software.
I bet you know what happens next. Sample SDW20 every second, then compare the register value to the previous value to see if it's changed. If not, begin cycling a 60 second self-resetting timer. Whenever this times out, it re-scans the V280 ethernet intialize and Modbus IP setup function blocks (normally a Power-Up Bit job). If comms come back on line, well and good, if not, it tries again 60 seconds later. This happens in the background, and does not affect the machine's operation.
Basically making the Uni yell, "Hey, dumba$$, over here!"
I'm going to take a little time and boil all of this down into a file I can upload for everybody's review, in case anybody finds it useful. Later today or tomorrow.
Thanks for all the help!
TM
The hardware :
Unitronics Vision 280 with ethernet option.
Make SURE you have the latest firmware - the modbus IP slave address of 255 no longer applies, and can be disregarded IF you have the latest firmware. Note, you do not get the latest frimware when you download Visilogic, it has to be done separately from within Visilogic using the Check for Updates function.
The Software :
Plantmetrics from Rockwell Automation
Configuration is pretty straightforward, but watch out for the bug described here :
http://www.plctalk.net/qanda/showthread.php?s=&threadid=10630
When assigning addresses to data points in Plantmetrics, use Matrikon aliases at you own risk. I couldn't get them to work, but I might have been making configuration mistakes.
Matrikon OPC Server for Modbus (plant based edition) from Matrikon Software
This software has it's own set of problems. Most critically, it doesn't poll PLCs once it loses contact with them, like RSLinx does (nod to Ken and company). When you lose a node in Linx, it looks for the node until it finds it or you tell it to stop by removing the node from the configuration. Not so, Matrikon.
If the machine is powered down, data collection stops (obviously). When the machine is powered up again, and the ethernet card is reinitialized, Matrikon takes notice and begins polling again.
If, on the other hand, you reboot the computer hosting the Matrikon software, and it comes up while the machine is running IT WILL NOT GO LOOKING FOR THE MACHINE! It sits there staring into space, waiting for the machine to yell, "Hey, dumba$$, over here!"
Now, to Matrikon's credit, it seems they've attempted to fix this problem with the "Check Connection" box on the TCP driver. Watching it's behavior, it seems to be polling every 5 seconds for a particular memory address to see if the PLC is out there someplace.
However, I cannot confirm this as yet, since the address the Matrikon software is looking for is not implemented in the V280 controller from Unitronics mddr So the box serves no purpose here.
Ah, but happy day, I have a work-around. In the V280 is a register
SDW 20, which is the default modbus register for sessions (packets) received. This will not increment unless actively scanned by the Matrikon software.
I bet you know what happens next. Sample SDW20 every second, then compare the register value to the previous value to see if it's changed. If not, begin cycling a 60 second self-resetting timer. Whenever this times out, it re-scans the V280 ethernet intialize and Modbus IP setup function blocks (normally a Power-Up Bit job). If comms come back on line, well and good, if not, it tries again 60 seconds later. This happens in the background, and does not affect the machine's operation.
Basically making the Uni yell, "Hey, dumba$$, over here!"
I'm going to take a little time and boil all of this down into a file I can upload for everybody's review, in case anybody finds it useful. Later today or tomorrow.
Thanks for all the help!
TM