- #Kepserverex unable to read block update
- #Kepserverex unable to read block driver
- #Kepserverex unable to read block free
- #Kepserverex unable to read block windows
#Kepserverex unable to read block driver
net driver if you want to avoid the scary DSC one: Įclipse foundation has been slowly funding a scada system which is getting slowly better and has decent support now: (not a server itself) You'd need kepserver to link to it but its there. I believe the shared variable engine always acts as an OPC device, regardless of if you have DSC installed or not. This also answers your wireless network question - it depends on the driver. So the answer is I think closest to "some stuff will go fast, some stuff will not". I believe the client-side updates work similarly. Kepserver at least has a threading model such that, for example, several modbus items in the same group will poll in series. First off each driver works differently, so for example a modbus driver would poll at a configured rate while the Mitsubishi driver might be able to use events of some kind. Its worth pointing out that an OPC server is just a plugin architecture with a bunch of drivers so i don't think you can reasonably quote performance numbers. I have had ethernet cables unplugged and PLCs taken out of run mode, and always had good recovery with that. I've never tried wireless, so can't fully answer about that one. It still has its applications.įor logging and alarming, I believe LabVIEW DSC has that built in otherwise you have to make your own. I expect OPC isn't as mentioned as PROFINET and Ethernet/IP have become more dominant. I expect that's an OPC spec rather than a KepWare limitation. I did have to break up a data block into multiple once it reached somewhere around 128 bytes as communication stopped above that limit. I've used KepWare before and have had nothing but good experience with it. OPC UA does not do this, so doesn't have the issue. Anything with normal or high priority can block the OPC communication for 10s of seconds.
#Kepserverex unable to read block windows
OPC goes through OLE which has the lowest priority Windows can assign.
OPC is meant for process control (the acronym is "OLE for Process Control").
#Kepserverex unable to read block update
Meeting your update rate could be problematic. Down side to a data block is having to parse out the information you're interested in. There is overhead with each tag that can be problematic. I recommend sending a data block instead of individual tags, particularly if you have a lot data.
There is a shipping example with LabVIEW on OPC using datasocket. I am familiar with OPC, so my comments relate to that save where noted. There is a big difference between OPC and OPC UA (this was pointed out to be on these forms, so I know there is at least one entry). I believe Mitsubishi PLCs also talk Modbus. How robust are the OPC connections in regards to reconnecting if a wireless connection is temporarily lost? What are the options for talking to OPC from LabVIEW?
What are the options for logging and alarming with OPC? Is OPC still popular, or are there other options for data aggregation that would be better suited to a new application? Is OPC typically low latency (time from data generated to to client received)?ĭoes anyone have a recommendation for a product (NI OPC, Kepware, etc.)? What are viable update rates for OPC tags? I will need at the very ( very) least 250 ms update rates. I would be very grateful if anyone has the experience to comment on the following or anything else related to using OPC. Unfortunately, I think I would have to use LabVIEW DSC (or datasockets.) to integrate the PCs. Unfortunately, I won’t have time to roll my own in the near future, but LVRT supports supports OPC UA, so I could potentially integrate the cRIOs fairly easily. I don’t see OPC mentioned very often (in fact it returns 0 results on LAVAG), and a lot of the stuff I see these days seems to be more “roll your own” or lower level (raw TCP/UDP, 0MQ, Network Streams, Transport.lvlib etc.) rather than a monolithic abstracting bridge like OPC. To do this, we would need to integrate our cRIOs and operator PCs into the OPC environment as well. Since I may be required to use OPC anyways, I was considering using an OPC server to aggregate all of the facility data, and then redistribute to control rooms, historical logging, etc. Now, we are currently expanding our data generating capabilities (hence the PLC), and I have been thinking about rearchitecting the way we collect data from all over our facility to be more flexible.
#Kepserverex unable to read block free
If anyone else knows a better way, feel free to stop me here. After a good deal of googling, I think the best (maybe only) way to get the data out is going to be via OPC, thanks to their proprietary Melsoft protocol.
I recently was presented with the task of integrating a Mitsubishi PLC into our systems.
0 kommentar(er)
