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.
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 am trying to recreate some features of Spotify in C# using the PostgreSQL database.
The reason is simple, I want to gain more knowledge, and I think this is a good challenge.
But I ran into an obstacle that I've been standing for days. Spotify he doesn't download the music, he does her streaming, plays the music while it's downloaded.
However, I can't do this in C#, I'm using the PostgreSQL database.
I'm well locked in this part, I tried several implementations, but I think I'm not on the right track, and on the internet I imagine I'm looking wrong, otherwise I would have found it.
Do you have any guidance for this streaming process in C#? I've tried to read the large_object bytes from PostgreSQL, but couldn't.
Any suggestions or guides about the process are welcome.
You start by getting the file into the database or its network location into the database, whichever gives you better performance; Then start with creating an implementation of a bytestream. You want to be transmitting raw data to c#.
you then build a real time interpreter that takes in using your file format, one byte at a time, and plays the value associated with that section. does that make sense? this is simple to do with many libraries and the brunt of it is just figuring those out.
You seem like you've PROBABLY got that first part down, and are instead having issues with the database. A lot of things we did at my last company involved saving file network locations and indexing files on disk. You might be able to instead point your streamer to a file locally using a server, and instead transmit data from one point to another in that manner instead.
You seem more than capable of doing this just judging by your speech. I hope this comment was helpful, and if it was not I apologize as well. I would be interested in seeing your finished result.
for clarification here would be that workflow:
request for a song listed in table dbo.Songs
matches that song onto dbo.songlocation
streams from dbo.songlocation.location from the filename dbo.songlocation.songname = dbo.song.name and verified directory returns true
enjoyment of that music
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.
What do you think is the best approach to solve this issue. I have a C# application that receives a XML list of files. Based off this XML list many files (~10 megabyte size) get copied from one folder on our local SAN to another folder on the same local SAN. But all those file copies transfer via the C# Windows App that is actually doing the file copying. This takes 20 minutes per job. Any good ideas on how to dispatch a set of copy instructions to the SAN via C# but not have the local box be involved in the transfer?
Does the Mono codebase offer a way to SSH into a box and execute commands? This is my only idea so far to greatly reduce the execution time these jobs take.
UPDATE
The SAN is the Clariion NS 480
http://www.tech.proact.co.uk/emc/emc_celerra_ns-480_nas.htm
I assume this is a Linux or Unix operating system inside.
Trying to find some better technical specs.
You could run a process on the SAN that executes a specific script every x minutes. Create that script from your c# application.
Usually I would use SSH from the C# application in such a situation to issue the needed copy commands BUT from the link you posted none of the protocols listed supports such a mechanism... neither SSH not TELNET (which I would NOT recommend for security reasons) is listed as a supported protocol... without such a protocol your only option is to have your local machine involved in the copy process... I highly recommend checking back with the vendor about SSH support...
I'm building a tool that consists of a Webservice that will run commandline tools at specific times. On average there will be running 15-20 CL tools at the same time. Every CL tool runs no longer than about 0,5-1 minute on average. The webservice needs to be able to check each CL's status every 2-3 seconds or so.
I've got some advice about how to do this; named pipes looks likes the best "technical" solution. However I'm wondering if communicating with simple very small text "status" files would be a better, less complicated and less error-risk, way. I prefer the solution that is the most resource friendly.
Please advice.
Named pipes would be better. You might run into access problems with the two processes trying to access the small text file at once.
I did something similar before and here's what I did.
I start the command line process by setting ProcessStartInfo.RedirectStandardOutput to true. Then I start listening to the command line process' output by doing:
process.OutputDataReceived += dataReceivedEventHandler;
process.BeginOutputReadLine();
Then in my dataReceivedEventHandler, I parse DataReceivedEventArgs.Data to see if my console application sent me a "message" that begins with a tag that I created (ex: "[ServerProgress]10").
So basically, the applications are communicating through the console output. Not elegant, but it did the job for me.
Hope this helps.
For your situation, status checks - not a huge footprint there, I'd go with named pipes any day. Using memory >> using HDD here.