rp74
02-02-2007, 09:40 PM
I am no stranger to this site... But, I sure would like to see a forum for .net development, along the lines of OPC, .net, HMI, ASP, AJAX, etc. Maybe something like ".net Developer's Forum", or some tangent thereof...
At work, I sit in front of a couple applications I have built, and have pondered performance.
I have a few applications that listen to a Kepware OPC server, WinForms - based .net apps. I have a question - WHY does it take so long for sync tx? If I WROTE the PLC interface, it would be lightning fast- I know it would be. I've written TCP / IP Socket apps before for other purposes, and they're just plain fast. However, in one OPC instance, I ended up sending a bulk syncread and processing the data as a whole because it was so much faster to do a bulk sync read than a series of sync tx / rx pairs. The OPC server WAS NOT taxed. This was the only app pulling from it at the time. I was cycling through 4 PLC's, doing some rudimentary handshaking. 1 Second wasn't fast enough- it took more than 1 second to do the sync reads / writes initially required - more like 2 or 3 seconds. Using the bulk-read method, I get cycle times of .2 to .7 seconds, which is JUST acceptable. I cranked up the polling sample rates in the OPC server (check for datachange) to 10 mS, and results were no different. This was talking to FAST PLC's, with built in Ethernet.
In another .net winforms app, I do samples at .5s, and cranked that up to .2s for testing with no problems (including a data flush to SQL Server on every read!). This is simply for syncreads, so it seems the problem is in syncwrites. This app ran for a few months straight at last run before I stopped it.
Maybe I'm expecting too much. Maybe I'm just not doing the math.
At any rate, it floors me that it takes so long processing transactions with an OPC server.
Equally frustrating is the 6 or so seconds it takes for AJAX to do a refresh in ASP using the same SQL Server (a sort of hybrid HMI app in ASP). Simply pulling AJAX out, direct refresh time is nill. Go figure...
Thoughts?
At work, I sit in front of a couple applications I have built, and have pondered performance.
I have a few applications that listen to a Kepware OPC server, WinForms - based .net apps. I have a question - WHY does it take so long for sync tx? If I WROTE the PLC interface, it would be lightning fast- I know it would be. I've written TCP / IP Socket apps before for other purposes, and they're just plain fast. However, in one OPC instance, I ended up sending a bulk syncread and processing the data as a whole because it was so much faster to do a bulk sync read than a series of sync tx / rx pairs. The OPC server WAS NOT taxed. This was the only app pulling from it at the time. I was cycling through 4 PLC's, doing some rudimentary handshaking. 1 Second wasn't fast enough- it took more than 1 second to do the sync reads / writes initially required - more like 2 or 3 seconds. Using the bulk-read method, I get cycle times of .2 to .7 seconds, which is JUST acceptable. I cranked up the polling sample rates in the OPC server (check for datachange) to 10 mS, and results were no different. This was talking to FAST PLC's, with built in Ethernet.
In another .net winforms app, I do samples at .5s, and cranked that up to .2s for testing with no problems (including a data flush to SQL Server on every read!). This is simply for syncreads, so it seems the problem is in syncwrites. This app ran for a few months straight at last run before I stopped it.
Maybe I'm expecting too much. Maybe I'm just not doing the math.
At any rate, it floors me that it takes so long processing transactions with an OPC server.
Equally frustrating is the 6 or so seconds it takes for AJAX to do a refresh in ASP using the same SQL Server (a sort of hybrid HMI app in ASP). Simply pulling AJAX out, direct refresh time is nill. Go figure...
Thoughts?