Really cool idea for Flowstone..

[fixstuff555]

Hello all,

I was thinking about something, and thought it would be something really cool. Maybe others have thought of it, but I haven't seen anything like it that I know of.

One wonderful thing about Flowstone is the ability to create EXE standalone files really fast. The only problem with this is that you either have to have a Pro version to make as many as you want, or can pay as you go. What would be nice is the ability to create standalone EXEs that are tied to a single computer that generates them (think hardware generated licenses tied to a CPU ID or something). This would allow DSP Robotics to prevent people making an EXE file and distributing it wily nily, but would allow some pretty wonderful possibilities. The main possibility I'm thinking here is lots of little "pebbles" (flowstone EXEs) that could run on the same PC and be interconnected via a background Windows interconnect, such as OPC UA or some type of DCOM interface (basis of OPC btw). This would give these little programs the ability to pass data between them, and allow Flowstone to leverage the multithreading, multicore ability of Windows to run a bazillion little programs. This would keep a Flowstone application from getting too massive and bogging down, and would isolate them as an object in essence. Flowstone could even be modified slightly to provide an editing framework for all of the little programs, with possibly a primitive or two that could be used as a simple way to interface to the outside world and to other programs.

At my job, I design controls systems that utilize multiple control points, and one of the ways I interconnect hardware across different vendors is OPC (Modbus TCP/UDP and Ethernet IP are some others). I can have multiple OPC servers residing on a single PC, and tie those different hardware systems together with a SCADA system. I believe that some of this functionality may be possible with Flowstone as it stands even now.

Since I own the Pro version, I don't have an issue with the EXEs, and I believe I can get some of this functionality by building an application with a client and server for each small program. This would allow a producer / consumer model of sorts, that would allow each program to produce data to connected clients as well as to go poll data from other servers.

For example, I could see a simple flowstone program that has a client, server, and comport primitive, that would simply be interfaced to a particular device on a COM port, say a servo board or something, and the interface to be available through the client / server interface. Any other program that wanted to use the servo could simply connect to the server and use the servo. Each server's port could be an ID that a master Flowstone program could have in its database.

I will look into this scheme further. What gave me this idea, was the Phidget webservice concept. Although it isn't mentioned much on this site when discussing Phidgets (other than the SBC app note) each Phidget device can be hooked up to a local PC, and be available for use to remote PCs. I have attached a sample program that shows the string to connect to the remote device. Keep in mind that the Phidget webservice has to be running on both PCs and the port your are using along with 5303 is opened up on both firewalls (UDP).