I know a BYTE is supposed to be sent, in the other flavors I was either sending integers or strings and it worked fine.
/* this method is from an example */
serialPort1.WriteLine(String.Format("{0},{1},{2}", (byte)Convert.ToByte(data[0]), (byte)Convert.ToByte(data[1]), (byte)Convert.ToByte(data[2])));
/* this does the exact same thing as above as far as result */
serialPort1.WriteLine(String.Format("{0},{1},{2}", data[0], data[1], data[2]));
I’ve tried other variations of above including sending each of the three values independantly, but this at least gives me a result.
looking in windows device manager, the baud choises seem to be 75, 110, 134, 150, 300, 600, 1200, 1800, 2400, and higher. Chosing a baud rate different than these might cause problems.
Muhaha! Welcome to my world! 900 and 600 are the two baud rates that produce results, albiet unacceptable.
All I am doing is incrementing 1 by 1 each time the light flashes. Note the change in direction and only the [0] slider moves. I’m open to suggestions.
so, and this probably seems like a really obvious question, does this minissc board actually support 900 baud serial? how odd that someone put that in there… because as you know, both the minissc and the computer need to have the same settings for baud, bits, parity, and stop bits… or you just get crap at the rx end on each device.
The MiniSSC-II from Scott Edwards supports only 2 baudrates. 2400 and 9600. The data is inverted which usually is the cause for tripping people up. They do have sample code on their website. seetron.com/ssc.htm
If you are actually referring to the SSC-32 then let us know…
I think the point is it ISN’T working at 900, it’s just sort of twitching, or you would not be looking for information. Just getting it to move in an unpredictable manner from end stop to end stop isn’t working.
It may be highly instructive to connect the serial port your C# program thinks it’s talking to and connect it via null modem cable to another PC serial port with just a terminal program running so you can see what your C# program is actually sending to the controller. Right now you appear to be just squirting bits into the blind and have no idea what is actually coming out of your program. You know the controller works at the expected baud rates with other programs/languages so you need to work through what it is about your program that is incorrect. You have zero chance of doing this if you even remotely consider sending a 900 baud serial stream to a device configured receive 9600 baud as “working”.
We finally fixed the time problem with the server, so because the posts are sorted by time and not post number we are seeing this wierd phenomenon. It should sort itself out in a few more hours…
Well I guess I don’t fully understand this reaction… unless you don’t know what a null modem cable is and you think it involves a modem of some sort, or you’ve found some other extremely simple method of seeing exactly what your program has just spit out the serial port that I’ve apparently missed out on all these years.
I know only enough to be dangerous and even that is a stretch.
The terminal program does seems like a useful to know how to do. What type of data will be output? As mentioned above, I’m a newbie, so will I be able to interpret/understand the results?
A null modem cable allows you to connect two PC serial ports together, whether it is COM1 on two separate PCs or two serial ports on the same PC like COM1 and COM2.
So say your C# program is sending commands out COM1 formatted for your controller. I’m really only familliar with the SSC-32 so drawing from its syntax the command might look like #0P1250T1000\r
to tell the servo output for port 0 to go from wherever it is to position 1250 over the next 1000 ms. The terminal program would display the exact string that was intended to go to the controller. So if the C# program were sending hex values instead of decimal values, or the values were getting truncated by an incorrect cast, or there were unexpected whitespace characters, it all would be readily apparent. If the program was sending at the wrong baud rate, or binary values instead of ASCII characters you would see crap (like viewing an .exe file with notepad) instead of the nice ASCII string with the numbers in it and terminated by a carriage return. The whole point is it lets you see what the controller will see when you connect it instead of the terminal program, instead of forcing you to interpret between what the controller is doing against what you think you told it to do.
I use a program called portmon that is free on the net that will show the serial port traffic. I’ve got a mini-ssc and it has worked well for 5 years. You can actually send bytes to it using batch files. Setting the baud rate for it at 900 will probably never work no matter how hard you try.
Yeah, OK. Admiting is the first step, just wish I tried that first, not last, and like those before me, I wish I had known sooner.
Lessons learned:
Java and C++ could pass integers and strings to the miniSCC-II but C# bytes].
Even though the miniSCC-II was made in 1996, it can still function at 2048 writebuffer (see the note about dangerous above). Sorry for doubting you Scott.
Normally the N word is not in my vocab, but with all the comments poo-pooing the 900 baud rate (the only one that showed results) I changed it back to 9600. Voila! It works with the miniSCC-II and the proprietary hardware, just like Java and C++.
Special thanks to EddieB for suggesting to monitor the comm port and russ for suggesting the port monitoring program. That enabled me to tap the inner Rainman and recognize patterns and relationships in the data.
