We Keep Coding

Implement multiple hardware interfaces in WPF Desktop App

I want to make a Desktop application with WPF(.net 5). In this application, I want to connect various hardware devices(sometimes simultaneously) via a USB port, Serial ports/Com port (e.g. RS232), etc.
I want the application to talk both ways. Receiving data from hardware devices with a range of configurations(i.e. baud rate, frequency, data string), and Sending data to display, modify settings of the device.
I don't have any idea about where to start in WPF | .NET | C#. Are there any inbuilt classes, APIs to achieve this?
Devices I want to connect are;
Serial port: Weight Scales, 7 Segment Displays, Liquid Analyzers
USB port: USB sticks containing text, JSON files; If one of the above serial port devices has a USB variant then those are too.

There is the Serial port class in .Net, but you might want to read some criticism about the class before using it. There are also libraries available to communicate over USB.
But these are fairly low level protocols that does not know what kind of device is on the other end. So your UI would therefore also need to low level, i.e. send/receive raw data. And this would mostly be useful for expert users using very specialized devices. While you could probably make the part that sends and receive data share an interface for both USB and Serial, connection and setup would probably need to be handled differently, since these are handled differently for serial and USB.
If you want a easier to use UI you would need to know more about what kind of device it it. There is a number of standardized USB device classes that specify what kind of device it is, and there are often high level APIs to interface with these devices. But that would require coding a module for each individual device class.
So I would recommend to start with figuring out what you really want to do? Connect to a IO board with some general purpose IO pins? Connect to some specialized device like a PanTilt unit? Read data from a webcam? Read some data from some kind of sensor, do some processing and control some kind of output device?

c# SerialPort MultiDrop connection

I have been reading up on the web and cannot find any information on working with a RS485 MultiDrop connection in c#
To give a bit of insight. I have written an application to communicate with a Serial device using the MODBUS RTU protocol. Now the client has informed me there devices may be hooked up using multidrop communications links. Being a novice when it comes to working with serial devices I am a bit lost here.
My question is simply: Where do I start? a Google search has thus far only produced hardware converters and wikipedia entries for different Serial Communication standards.
Thanks!

RS485 is a standard that defines the electrical characteristics of a particular multi-drop networking arrangement. I once used it as the internal bus for an instrument - the main control board drove various pumps which were arranged on an RS485 network.
You can get half-duplex and full duplex arrangements (half means that one device can talk at a time - full means send and receive can happen at the same time).
Really using it is not a whole lot different from using an RS232 or serial port, and as you've seen you can get serial to RS485 converters. You can use the serial port drivers in C# to use it.
SerialPort Class
Your main problem is that RS485 doesn't really address how it should be used - its a fairly low level electrical spec, it doesn't define how you should use it to make communication happen.
The main issue you need to consider is how you're going to coordinate all this. With RS232 - there are two things connected, which makes it easy - usually a computer and some device. With RS485, there are many things connected. So you need some way of addressing each device. You don't give any details about the 'device' referred to here - but if they are intended to be connected on RS485 - then there will be a way of addressing them. There are however several ways this could work - so I can't help you on specifics without more detail. With the system I developed, all communication was initiated by the 'master' device (i.e. my control board - or your c# application for example) and each message sent had the receiver's address on it - so the right pump knew that the instruction was intended for it.
I hope this is of some help. Really its not that complicated, but you need to think about what these devices do, how they are addressed, and think about the messages that you need to send back and forth. You can use the C# SerialPort classes to actually do the work.
The book referred to in the other answer looks great by the way. I really would consider buying it if this is all new to you. It covers serial port communications, and has a chapter on RS485.

I have not worked with RS485 but this book can be a help in understanding Serial port and USBs.
here is another link which discuss specs and here is another. I dont think they will be readily implemented in C# but could be.

C# COM port communication - errors with a USB to Serial Adapter

Here's the scenario - I have a C# application that reads from a COM port. Most of the time I use devices with a serial adapter and on a machine with a serial ports. However, machines with serial ports are increasingly difficult to come by so I have started using machines with a USB/Serial connection.
In some cases, the C# code that I have will work just fine with a "true" serial connection but fail with a USB/serial connection. The data comes in fragmented with the first part of the data coming in (like maybe the first 1 or 2 characters) and nothing else.
I'm using something basic like comport.ReadExisting() to pick up the data from the port. Is this part of the problem? Are there other methods that would guarantee that all the data would be read in a single string?
Finally, I want to add that I've already played around with some of the USB/serial settings in device manager AND the data comes in fine when using good, ole' hyperterminal . . . so it has to be something in the code.

With USB-serial converters, you MUST set your receive timeout, because the data can sit in the USB device for a long time where Windows doesn't know about it. Real serial ports hold data in the 16550 FIFO where the Windows driver can see it.

Most of the times you would want to use the SerialPort.DataReceived event ( http://msdn.microsoft.com/en-us/library/system.io.ports.serialport.datareceived.aspx ).
This requires you to combine the chunks of data manually since you can receive parts of your string, but once you detect the boundary of a single 'record' you can fire of processing that record while letting the IO receive more events.
This allows some asynchronous IO which doesn't block your threads, and thus allows more efficient handling of the data in general. If it helps in your specific situation I don't know, but it has helped me in the past dealing with data reading issues, low speeds, thread pooling, and lock-ups.

How can I send a message from a VB6 application to my C# application

Hi have a VB6 Windows application (old.exe) and a separate C# Winforms application (new.exe). They both run on the same Windows machine.
I have access to both the VB6 and the C# source code, but the apps need to remain separate.
If both are running and have knowledge of each other (process Id), what's the best way to send a message from one window to the other?
Update:
In this case, I'm only talking about very infrequent and small messages - e.g. change the tab you're looking at using a small message like, "Invoice 67"
Bi-directional messaging would be great, but VB6 to .Net is the most important.

Neither of the two prior answers consider the fact that this may be a multi-tentant environment or even span you domain. As you move into distributed systems you shold consider messaging as opposed to inter-process communication, which over time will limit scalability.
For on-premise solutions consider MSMQ, there is a multitude of documentation out there, demonstrating the simplicity of this messaging infrastructure.
for broader scenarios, you should consider Windows Azure Storage Queues, you get an almost identical usability, but with a broader accessibility and improved management tools.
MSMQ is domain-specific, by Azure spans the globe.

Agreed with Clay's comments.
However, I'll take a stab in the dark and go with the most obvious answer:
.NET (w/ WCF) supports both IPC and Named Pipes for local intra-process communications.
Here's a link on the topic using named pipes... but it's super old, and doesn't use WCF like it should... but the point is the same: http://www.switchonthecode.com/tutorials/interprocess-communication-using-named-pipes-in-csharp Updated version using WCF: http://www.switchonthecode.com/tutorials/wcf-tutorial-basic-interprocess-communication

Here is a more-or-less complete list of IPC alternatives for Windows.
http://msdn.microsoft.com/en-us/library/aa365574%28v=vs.85%29.aspx
Most of them can be utilized from VB6 and C# as well.

The solution that I have used for this very purpose is to have TCP communications between the processes. It allows for bidirectional communication. And as a bonus, should you ever move one of the applications to a different box, your apps will continue functioning with very little changes.
In .NET, you can use a plethora of classes for this purpose (ton of stuff from low-level to high-level in System.Net). In VB6, you could go with the Winsock control that ships with the IDE. I use Dart Winsock control (costs $$$), just because it is so much more flexible.
I set up both apps to send/receive XML fragments with a known schema. There is typically an attribute that tells the other app the type of message being received, along with the payload.

A basic solution (based on the info provided):
Create a dedicated folder for incoming and outgoing messages (the one applications incoming folder will be the others outgoing folder)
Write messages (or data) into text/xml or other format to the output folder (adding a Source field so the application knows where its from)
Read the messages, based on date, and import messages/data
This allows integration to/from any application.

The Ultimate Answer To This Question
VIRTUAL NULL MODEM:
http://en.wikipedia.org/wiki/Null_modem#Virtual_null_modem
From Wikipedia:
A virtual null modem is a
communication method to connect two
computer applications directly using a
virtual serial port. Unlike a null
modem cable, a virtual null modem is a
software solution which emulates a
hardware null modem within the
computer. All features of a hardware
null modem are available in a virtual
null modem as well. There are some
advantages to this:
Higher transmission speed of serial data (limited by computer performance
only). Virtual connection over network or Internet is possible, mitigating cable
length restrictions.
An unlimited number of virtual connections is possible.
No serial cable is needed.
The computer's physical serial ports remain free.
For instance, DOSBox has allowed older
DOS games to use virtual null modems.
Another common example consists of
unix pseudo terminals (pty) which
present a standard tty interface to
user applications, including virtual
serial controls. Two such ptys may
easily be linked together by an
application to form a virtual null
modem communication path.
With the HIGHLIGHT of this solution being: IT REQUIRES NO CABLES!!!
*Note; This is an attempt at humor. Forgive me if it's not funny.

Need to control some device via Wi-Fi using C#

I am working on an application that needs to control another device.
This control should be using Wi-Fi.
How can this be done in C#?
Important to know that the other device I want to make it.
I can afford the part of making and design but how to make it connect to PC using Wi-Fi?
I don't know about it.
I just need a key to start searching or some thing similar.

Connecting over Wi-Fi could be as easy as opening a socket on the server, and another on the client, and start streaming data. Of course this if both devices are compatible and has Wi-Fi receivers. Just think of them as two computers connected with a wire, or without a wire they will just behave the same.
The connection protocol will care about doing the magic of converting what you write on the socket, into RF signals received from the other device and converted back to bytes.
But if you are building your own antenna/receiver/protocol ... then things will be much more complicated.

If you have to ask then you're probably going to want a single board computer. Popular choices are:
gumstix
Zii EGG
nwg100 by Atmel
(XBee) --not too sure about these, I haven't used.
You can install a network stack and everything on them.