What Do I Need To Learn Beside C Sharp To Make a GUI ThatCommunicates To A Machine???

  • Thread starter Thread starter Michael
  • Start date Start date
M

Michael

Could someone please give me some direction?

I want to create C# GUIs using Microsoft Visual Studio because I like
the way they appear. (I do not know how to program in C# yet.) The
GUIs I create on one computer will need to communicate with a machine
that has an on-board computer running a C Program in the LINUX
operating system. The machine will plug into a router or switch using
a standard cat5 cable/ethernet connect on a local subnet where the GUI
computer will also have access to the internet. The GUI will store a
list of variables and their values and then issue a sequence of
commands -- one at a time -- for the machine to execute. Real time
operation is not critical since the machine's onboard computer will
stop after each move as it waits for another command.

My background is mechanical / electrical engineering and computer
repair.

My question only pertains to the computer running the C# GUI. Can
someone tell me what other topics besides C# programming I may have to
learn to accomplish this? (SSH, .NET????)

Thanks and sorry for the novice question!!!
Sam
(e-mail address removed)
 
The
GUIs I create on one computer will need to communicate with a machine
that has an on-board computer running a C Program in the LINUX
operating system.
Click to expand...

Absolutely the first question you need to answer is "What type of interface
does the Linux-based program use to communicate with the outside world?" In
other words, is it listening on a socket? Is it monitoring a folder for
files containing commands? Etc. Without this information you can't go
anywhere.
 
Thanks for the response!

I would like to have the machine's onboard Linux computer keep two
ports open:

1. port 22 - Secure shell (SSH). This will be used to configure
some kind of files storing many parameters and constants for reference
by the C program. Last posting, I incorrectly stated parameters would
be stored on the Windows C# machine. Instead, all configuration files
will be stored on the Linux machine but changed by the C# GUI on the
Windows computer.

2. port 1000 - A text based ethernet socket connection that will
communicate using some protocols that I have yet to define. An
example might be: move x 7000 This means to move axis x 7000
encoder counts in the positve direction.

In Summary:
The Windows C# GUI will need to work on XP, Vista or 7. The Linux
machine will be running a C program at the same time that the Windows
computer is running the C# GUI. (Exception: C will not be runnig
while port 22 is used.) The GUI will issue commands to the C program
via port 1000 and then wait until the C program returns a response
(complete, error, etc.).

I may later find that some other ports are better suited for this
purpose, but for now my selection is based on what a company I used to
work for had implemented. Also, I am far from and expert in Linux!

Thanks!
 
Michael said:
[...]
I may later find that some other ports are better suited for this
purpose, but for now my selection is based on what a company I used to
work for had implemented. Also, I am far from and expert in Linux!
Click to expand...

Assuming the machine's network card is dedicated for this sole purpose,
you could be able to use whatever port number you like.

As for the Windows side, .NET has a variety of good network i/o classes.
The System.Net.Sockets.Socket class is a nice managed version of
socket APIs you may have already used, while the TcpClient class in the
same namespace abstracts the socket a bit more. Either would be likely
to work well.

Note that the GUI aspect itself has (or at least should have) nothing
really at all to do with the i/o side. You should be designing your
program with a general purpose network i/o class specific to the machine
you're communicating with, and then the GUI can use that class. If in
the future you need to communicate with the machine based on other
input, you can reuse the network i/o stuff without dragging all the GUI
code into the picture.

Pete
 
As for the Windows side, .NET has a variety of good network i/o classes.
  The System.Net.Sockets.Socket class is a nice managed version of
socket APIs you may have already used, while the TcpClient class in the
same namespace abstracts the socket a bit more.  Either would be likely
to work well.

Note that the GUI aspect itself has (or at least should have) nothing
really at all to do with the i/o side.  You should be designing your
program with a general purpose network i/o class specific to the machine
you're communicating with, and then the GUI can use that class.  If in
the future you need to communicate with the machine based on other
input, you can reuse the network i/o stuff without dragging all the GUI
code into the picture.
Click to expand...

Pete -
Thanks for the ideas! I don't understand the structure of C#
programming yet but I can look up the .NET network i/o classes. Also,
the modular aspect you mentioned (keeping the i/o side separate from
the GUI) is very helpful since I would like to make different machines
that use different GUIs and yet reuse the communication code section.
I'll have to research the port number selection....
 
Back
Top