I am writing an application which communicates with a network analyser using ivi.visa from Keysight. I often work remotely where I don't have an instrument, so I decided to write an application that can respond to the SCPI commands I need. This works ok for things like "*IDN?", but when I try to receive a binary block using ReadBinaryBlockOfByte(), the call terminates when it sees a newline character in the data.
If I set TerminationCharacterEnabled to false, all reads timeout. This is mentioned in the Keysight visa.net examples, so it doesn't seem to be an option.
So how can I read binary data?
Related
What I'm Trying to Achieve
I'm attempting to build a console game that has multiple console windows that would be displaying inventory, status effects, current map, and health. Another console would be the main one that gathers input to effect the other consoles. The reason I want to do it this way is so that the other consoles can be updating their "graphics" (or text) without disturbing the input flow.
What I've Tried So Far
So far, I've attempted to use System.IO's File, FileStream, StreamWriter, and StreamReader to communicate between the consoles via text files. The problem I've ran into is that, when the main console (the input console) is attempting to write inputs to a file--which is communicating with another console (the "graphics" console)--it throws an error because the "graphical" console is trying to read the input of the file (or vice versa).
I figured that making the FileStream's FileAccess be Readable would do the trick, but I ran into the same issue.
I think I could get this to work if I could communicate between the consoles to tell each other that one is done writing to or reading the file... kind of like a back and forth... "I'm writing to the file... okay, I'm done" "I'm reading the file... okay, I'm done" and the cycle continues...
So, in summary, I suppose, my question is how can I communicate between two consoles using files?
Possible Solutions I could try learning SQL, but I don't know if I'd end up running into the same issue... so, if I must learn SQL for this project, I suppose, that'd be my last option.
Thank you!
IPC (inter process communication) is the keyword you're looking for.
There are multiple ways to do IPC, e.g. shared memory, named pipes or similar. .NET has an IpcChannel which uses TCP or a named pipe if the destination is on the local PC.
I'm trying to send data from a python script to my c# application using a standard input stream. I also need to eventually send data back from my c# application to the another python script. I first tried to do this with a UDP Connection which works fine for a couple lines, but I have a fair amount of data to send (a few thousand lines) and a requirement for data integrity which UDP cannot provide. I could also write to a file, but that seems very inefficient.
One last restriction is that while my two applications are related I cannot setup a direct connection between them using something like IronPython as they are both spawned separately by a 3rd party application.
This is what I am currently trying, but it is not working. Similar to this question: Passing data between Python and C# without writing a file
p = subprocess.Popen(C_SHARP_EXECUTABLE_FILE_PATH, stdout=subprocess.PIPE, stdin=subprocess.PIPE, stderr=subprocess.PIPE)
p.communicate(blob)
On my C# side I'm not entirely sure how to read this data, but I've tried using things like a loop around this:
Console.ReadLine()
or getting the standard input and reading from it directly using:
Console.OpenStandardInput();
The current issue is that as soon as I call p.communicate my Python script gets locked and doesn't proceed. If it's waiting for the line to be read, what do I need to do to make it stop waiting? I tried only providing the stdin parameter, but that didn't help.
I am looking to transfer a binary file via RS232. I need to do this to 5000 different devices (no joke). I could do them one-by-one through a terminal program but that will take a lot of time.
So, I am writing a C# program that will be able to automate the process. I am looking at using XMODEM protocol and command line parameters to start the process. I have been looking for this for a few hours now and far my results have turned up little. I tried using uCON but that takes some sort of scripting language.
I was wondering if anyone in the community here might know of a solution to transfer a file over RS232 and program it in C#. Whether it is from a protocol (XMODEM) or a program that accepts command line or some other custom solution, doesn't really matter to me.
Ok so I was able to confirm that the code found on the website( ghielectronics.com/community/codeshare/entry/825) was able to work. The issue was was that I did not know how long it would take the computer to transfer the file. I thought that it would be quick. However, after further testing, it actually takes about 30 sec to 1 min depending on the file size.
This C# code snippet allows anyone to transfer a binary file over the Serial Port using the XMODEM protocol. This is done in code and a terminal is not needed which fits the requirements that I needed for the project.
I must have looked through hundreds of articles related to the StandardOutput ReadtoEnd halting but none of them seem to answer my specific question.
The scenario I have is that I'm creating a wrapper for a 3rd party console app to be used in my ASP.NET MVC application. I start the process, pass it an input string (which is a dot file in string format) and the app returns a file (pdf in this case).
The file is placed into the stdout (according to the docs) however I don't seem to be able to read the data out.
When I run the console app manually, I receive the file as text in the output window but the program never really "exits". I have to CTRL+C to end the process.
I'm guessing this is why my calls to
process.StandardOutput.ReadToEnd();
Just hang?
Can anyone shed a bit of light into what I'm doing wrong. I'd like to return the file that's received in the output as a byte[] from my method call.
Thanks and appologies if it seems like this is a duplicate.
There are two problems:
ReadToEnd() returns a string. That's no good idea, if the data is binary
ReadToEnd() doesn't return, because the program never exits
Because of this, try reading the underlying stream (process.StandardOutput.BaseStream) with the more low level stream methods like Stream.Read and detect yourself when the program finished sending its data.
I have written a program in .NET that listens to a particular Serial Port and processes the data that is being received. I wrote a test program using com0com (the Null-modem emulator) and my program was working fine. I even tested it with HyperTerminal and that seemed to work fine too.
However when I interfaced the software with the original device (an output received from a control system), the data received was garbled. It contained special characters. The same device when connected with Hyper Terminal produced the desired output. I changed the baud rates, parity etc but the data received was the same set of garbage characters.
I have used the DataReceived event of the SerialPort component and used the following line of code to capture data:
string data = portRecieve.ReadExisting();
Can somebody tell me where am i missing out? In the current environment, the output from the device is directly connected with a dot matrix printer which prints whatever is received on the port. The printer seems to catch what is being sent but my code couldn't.
If you ever encountered a similar scenario, Please share your findings.
Thanks
How did you set
SerialPort.DiscardNull
SerialPort.Encoding
And maybe show us an example of the special chars you are receiving.
I can think of the following reasons why the data might apperar garbled:
If there is a bad physical connection, you can sometimes just get garbage (rather than nothing at all). Try unplugging and replugging the leads - and check that you have the correct lead (e.g. do you need a nullmodem?). It looks as though you have this covered by checking in HyperTerminal.
If the baud rate, stop bits, parity are not correct - sounds like you have this one covered
You are trying to receive the data as a string. If it is not sent as plain text, or if your encoding is wrong, then it could easily appear garbage-like. Try using a binary receive and examine the raw data that you are receiving. This will tell you whether the data is just wrong or the .net conversion is screwing it up - eliminate the middle man!
It sounds to me like the device is putting the printer into some special graphics mode. If so, there is likely to be escape sequences in the data being sent to the printer, ie. character sequences starying with an escape (27, 0x1B) character.
In this case, you'll have to look at the printer manual to see what the commands do. Alternatively, you might be able to tell the device to use a simple ASCII only printer, rather than a intellifent one.