I am working on a software manager (GUI) for instruments that I manufacture. It will interface to a variety of real hardware instruments and dummy demo (virtual) instruments. I would like to make this modular (1 module = interface for one device type) so that it can be expandable over time, with one module per instrument. Instruments normally connect by USB, so for real instruments, the module will just implement the serialport-over-USB for that module. For virtual instruments, the module will be a full instrument simulator with everything going in and out as if it were using serialport-over-USB.
In past eons, one of the ways of doing this was tcp/ip. Is this still a recommended method when the host app and the modules all within the same machine and across operating systems? If so, is any of the protocols (e.g. udp, tcp, etc) more appropriate? If tcp/ip is not recommended, what DO you recommend?
What is the recommended location for such modules?
Is there a recommended way for the host app to learn what modules are present? I can see some kind of scan mechanism and I can see a text-based index list in the module directory; any better way?
Any comments or suggestions about designing such a system would really be appreciated.
Many thanks
Jim Wagner
Oregon Research Electronics
I would say use TCP for the communications link and Xojo’s AutoDiscovery classes to detect which modules are available. The advantage of this approach is that it makes this part of the system network transparent: it doesn’t matter if the module is running on the local machine or a server, it will function exactly the same.
I don’t understand the suggestion. Well, about UDP, I do understand. But bluetooth is a wireless channel, and does not seem to fit the need to communicate between software “apps” on one host machine. Non-serial non-usb would seem to require each “app” making live data visible to others, and that would, in my mind, involve some severe atomicity issues. TCP seems to fit the bill pretty well.
But, that leaves open the question: where to put these “plugin” helper apps?
For industrial control systems, TCP/IP was fairly standard communications protocol between devices on many of the project I worked on. You may also want to check out:
which is a popular control protocol built on top of TCP.
Thanks about info on Resources folder. I can temporarily put those files somewhere useful on Windows while I develop. Have no clue about linux.
I have the external protocols under fair control. What I tried to ask here is about what to use between the host app and its “plugins” on the same machine. Looks like it will be TCP, especially with the Auto-Discovery capability.
Still open for a plugin storage location on linux.
Not that I fully understand what you’re trying to accomplish, but what about a common SQLite file in a known location, e.g., SpecialFolder.ApplicationData + [app name]?
IPSSocket is very fast and good for transfers of large data between processes on the same machine. However, you lose the flexibility of being able to use other machines on the network to host plugin processes. Choose wisely. And honestly there’s no reason to choose: you could easily support both connection methods in your code.
And honestly there’s no reason to choose: you could easily support both connection methods in your code.