> OK, so the solution (as you have already stated) is to make another OCX > which uses the serial comms OCX and implements the Modbus specific logic.
Yes, that's what I intend. > > This is why the VB code or the control need to block until the full > > response is ready or a timeout occurs, to avoid this possibility of > > crossed comms. > > Then why won't you wait on the I/O in the UI thread itself? > What's the use > of the worker thread in this case? Because if the device did not respond for some reason, the main thread would be blocked forever - it needs to timeout so that the main program can move on. For example, say the user is trying to just see what the contents of register 56 are. They click the Read button, and that starts the comms. It must either return the value that was there if the device responds in time, or it must pop up a message to the user saying that the device did not respond (timeout). It MUST NOT get locked up waiting for a non-existent response. It's also in future preparation for having groups of values read asynchronously, in which case we don't want them interfering with the main thread. This is similar to OPC behaviour - you can read a value directly from the comms, or you can read it from a cached copy, which has been updated on a regular basis by a background thread. For now, in the programs I'm working on, I have to stick to the read directly method. -- Jason Teagle [EMAIL PROTECTED]
