I know that there is similar question answered, but the answer doesnt satisfy me.
At first i will explain my situation so that you understand, why i really need to communicate one com port twice.
I have to communicate with microcontroller by COM port. This microcontroller passes my messages to some devices. But it also provides transparent communication with some other controller. Working with this controller is quite difficult, but there are dlls provided for c# by producer. The problem is, this libraries make communication with chosen com port(in a way i cannot control), so that i dont have access to this com port later (it makes communicating with other devices impossible).
Is it possible to communicate to same com port twice? If it isnt, i will have to forget about provided library and write some code closer to metal, which will cost me a lot more time.
Related
im working on a project where i should transfer data from a c# server to an Java client (running on android device).
i need to use UDP protocol for a real time data and to maintain performance.
searching the web. didnt find any similar example and i really dont know where to start.
can you please suggest if this can be done ?
Thanks in advance.
Yes, it can be done. That's one of the beautiful things about the Internet protocols: support for standard sockets is so widespread and common that disparate devices running vastly different CPU architectures and software environments can interoperate with nearly no trouble.
Please make sure that UDP is really the best tool for the job. Do you need reliable delivery? Do you need in-order delivery? How much packetloss can you tolerate? How much packet re-ordering can you tolerate? Will your application handle 540 byte packets as gracefully as it will handle 1500 byte packets? Does your application need to protect against man in the middle attacks? How?
TCP is an incredible protocol. Many attempts to use UDP "for speed" wind up re-implementing many of the things that TCP provides for you already -- but most re-implementations are not done nearly as well as the real thing. Please don't be so quick to dismiss TCP.
To get started, just about any network tutorial for Java and C# should include something like a chat or echo server, the network programming equivalent of "Hello World". And that'd be good enough for a simple environment. If you intend for your server to handle dozens of clients simultaneously, it'll be more work, and if you intend for your server to scale into the hundreds or thousands, it'll be a different style of programming altogether.
Have you tried reading this:
http://nickstips.wordpress.com/2010/09/03/c-creating-and-sending-udp-packets/
The client is irrelevant, it can be Java, C++, or any other language/platform. Doesn't matter.
The protocol is still the same.
Hope this helps.
Try the Oracle Documentation as a starting point with UDPs, there you can find an example which i in java but as mentioned the idea of the protocols is to support a language independent communication.
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.
I'm rewriting a legacy app that sends pager messages via TAP and modems. So I'm having to write a new TAP client in C#. Using SerialPort is trivial but I'm not sure about how to handle conditions such as:
excessive ringing with no answer
no dialtone
busy signal detection (I understand that this isn't enabled in every modem so this is optional)
remote modem answers
Then also how do I read received data in a synchronous manner? TAP is synchronous so I will be issuing commands and then expecting some type of response from the remote machine. I think my biggest issue is figuring out how data will be terminated. Is it standard for modem data to be terminated by a CR or maybe CR-LF?
Some pointers would be great and any references that I could go read myself is wonderful too.
Is this a question regarding Serial Communication or the TAP? I've never had to work with TAP, but I have had to work with serial communication hardware (albeit quite a few years ago.)
I just found this PDF specification document and I searched for "terminat". It brings up 8 different words with that series of text, 7 of which appear to be in reference to your request.
I'm not sure of how much experience you have with serial communication or legacy communication systems & hardware but you may find HyperTerminal to be immensely useful and it is part of Windows. There is other serial/terminal software out there, but HyperTerm is free and simple to use.
You can use HyperTerm to send and receive codes to your devices and inspect the data that is sent/received. Then, you can use the communication dumps to reverse-engineer the TAP communication.
-- EDIT --
In regards to interacting with the modem, I'd research a bit about the Hayes command set. Hayes was a company that made modems in the early 80's. According to what I've read their modem commands have become pretty standard ever since then. Glancing at the available modem commands, I think there is a solution for your questions but you may need to do a bit of experimentation.
I'll be honest, I've never had to work directly with modem hardware, so the information that I am providing is based off of the research I've found this afternoon. These tips are what I would assume and attempt if I were in your shoes. For more information, google "Hayes Command Set" or check this article.
Hope that helps.
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.
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.