Send Motor Status to another PC?

[Insider1984]

Hi, I'm looking to send some very simply and non timing critical information from a PC that is controllin a bunch of motors to another PC that has a central GUI that is mostly there to just monitor the status of this and 5 other PC's.

I'd like some suggestions on the technology that could be used to do this. I've looked at Windows Message, .Net Remoting, etc but I havn't dig deep enough until I got some advice from others who have done similar things.

Requirements:
I want something very simply to use since time is not of concern. However CPU usage is a concern (use as little as possible)
Easy and Clean:
I'd like to send the command at all times and if the GUI on the other PC is available, it would take it and update. If the gui isn't available, the original motor controlling PC would be okay with it.


The way I used .Net remoting in the past was a little wierd, I required me to startup one application first then the other created an instance of a class from the other. I didn't like this because it would make the two applications 100% dependant which for me is a very bad design (both can and should be used separately in any case.

Any thoughts are appreciated.

=====================
Insider
4 year 'on the fly' programmer
C, C++, C#, MFC, Basic, Java ASP.NET

 

[Tarwn]

Why not go back to the basics? Create two applications. One application resides on the system controlling the motors, the other on the remote system.
1st) Whatever you need to control the motors, some functions you want to expose, and a socket
2nd) GUI and ability to make a socket connection to 1st.

So you define your own little mini-language. Each method that needs to be called on the first could have a prefix and take whatever arguments are needed plus an extra little code for "data". The 1st machine would parse incoming data and run the appropriate methods. Meanwhile, after connection, the 1st machine would start sending data at an even rate. Perhaps setup a thread-safe queue for outgoing data, anytime a method is called, dump it's return method into a queue with the same code/prefix that the 2nd machine calls it with. Setup a thread to dump the current data onto the outgoing queue every second.

If you don't care so much about saving a some overhead on the network, then we won't bother with compressing the data stream. I would suggest the packets back and forth be formatted something like:
Type: 1 char - is this a method call, result, data?
Name: x chars - method name, data point name
End Char: 1 char - end of name char
Value: [depends] - depends on type
Data - Just a value of whatever length
Function Call - Delimited Arguments
Function return - numeric code: 0=success, andthen make codes for other common failures


Taking this one step further, you could actually have the 2nd machine request which pieces of data it wants from the first machine. You would have two decisions to make. Either the remote machine can poll each time it wants new data (polled data) or it can "sign-up" with the local machinbe to receive updates, and then the local machine just sendsit updates on those values every once in a while (registered data).

Polled data would be extremely easy. Basically the 2nd machine would just have a list of what data points you want and a thread would send data requests with some identifier for that data point to the 1st machine, which would just respond with the data code, name of the point, and value. This puts the load on the remote machine to actively poll though.

Registered data would also be fairly easy with the infrastructure we built above. Create a new kind of code for the 2nd to send to the 1st that consists of the code and a point name. The 2nd adds the item to the it's list and starts up a thread to send updates back to the first every second for that data pont. Extend that communications to three fields and you can make the third field a boolean "signup/cancel" to add or take a point off the list.


If you want to get even crazier you could add IP addresses to the list of what points to send updates on, and therefore allow multiple clients.

I realize this may not be what you were looking for, I'll let other people make suggestions now, I think I hve been around manufacturing and process equipment too much lately

 

[Insider1984]

I like the ideas and it's similar to something I started over the weekend but polling is certainly not an option.

Is it possible to have a receiver that sleeps until it receives a remote command using sockets?

Sorry, I realize that .net has made sockets very easy and I'm looking into how they work exactly but in the meantime I do not want to start down a path that involves polling.

Thanks for your great input Tarwn!

=====================
Insider
4 year 'on the fly' programmer
C, C++, C#, MFC, Basic, Java ASP.NET

 

[JurkMonkey]

Look at Remoting.

http://www.microsoft.com/downloads/...f8-033d-420b-a3b1-3074505c03f3&displaylang=en

You can download the samples here.

 

[Tarwn]

Like I said, I was getting a bit carried away. Most (I hate to say all, but it maybe all) industrial/manufacturing data historians/io servers use either polling or some method of signing up for updates.
Remoting just seems heavy for what your trying to do. Even with .Net this app shouldn't need to much in the way of resources unless you start managing thousands of updates per second. However it may be easier, despite your past probles with it, to use Remoting.

As far as the receiver is concerned, if you planned on going with sockets it should be as easy as using a TcpListener asynchronously. There are some complications, depending on how re-useable you want to make it. If your just hard-coding things for now then you shouldn't need to worry much about have the receiver sign up for updates or anything like that. Depending on how often your updating, you may want the other machine to go into a slower communications mode if your receiver is unavailable. For instance, if your sending data back to the receiver roughly 10 times/sec and then the receiver disappears, you may want to just start trying to connect every 20 seconds until it comes back in order to save your system the time of waiting for all of thoe TCP timeouts.

 

[Insider1984]

Hi, thanks for the update. We decided to go with sockets and I love it. Very easy.

BTW, we'll be getting updates like once time every 5 or 10 seconds (more for end user notification of status on our "Black boxes"

thanks for all your help.

=====================
Insider
4 year 'on the fly' programmer
C, C++, C#, MFC, Basic, Java ASP.NET