09-08-2011 01:22 AM
Gidday,
I am just starting out with the labview code.
(C#) Same cables, computer, and software versions.
I am just playing with the advance read and write for the time being.
The Read only spits of serial. Which makes me wonder. Is it expecting a string of characters, where as this microcontroller is only spitting out 1s and 0s so it won't make sense. - If you follow my thinking.
K
09-08-2011 09:07 AM
You really need to find what settings the C# code is using. There is more to a serial port than simply the BAUD rate. As Steve said, the C# code looks like it is doing normal serial communications. THis means it should work in LabVIEW. I suspect the port is configured in a atypical manner. You need to find out if it is using something other than 8-bit data, look at the flow control, parity and stop bit settings.
09-08-2011 11:02 AM
@Kamilan wrote:
Gidday,
The Read only spits of serial. Which makes me wonder. Is it expecting a string of characters, where as this microcontroller is only spitting out 1s and 0s so it won't make sense. - If you follow my thinking.
K
The microcontroller IS only spitting out 1s and 0s.
Here is what happens under the hood in the UART in your PC. When idle the microcontroller will hold it's TX line high. When you are this low level a 0 is referred to as a "space" and a 1 is referred to as a "mark". I think this goes back to Mores Code. The first thing that happens is that the microcontroller will send a space which is interpreted by the UART as a start bit. It will then send between 5 and 8 data bits (configurable) starting with the LSB. The final bit is the parity bit (odd, even, space or mark) if parity is enabled. After this a stop bit or two (configurable) is sent which is a mark. If there is a space following the stop bit there is more data and this is it's start bit. If it holds a mark this is a break signal.
What is the point of all that? The UART in your PC is a little state machine. Neither LabVIEW nor your CPU have any knowledge of what is happening there. The UART frames the data on it's own into a buffer and the data shows up as bytes from the VISA read. But both sides have to have the same settings. How long the marks and spaces are (baud), parity setting, how many data bits and how many stop bits. You will see things like 9600 N81 which means 9600 baud, no parity, eight data bits and 1 stop bit. If these settings are wrong you will get garbage. If there are framing errors due to a missmatch then the UART will probably discard it and you will not even see the garbage.
There is something else called the termination character which is above all that low level stuff. This only determines how the VISA read works. If termination is enabled the read will stop as soon as it sees this byte character. You can tell it to read a million characters but it will stop and return everything as soon as it sees the termination character.
Are you using VISA or the low level serial functions? You really should use VISA as it makes things much easier.
09-11-2011 07:55 PM
Ok, So I have looked through the code and found this
// Request Data from base station
#region write
byte[] toWrite = new byte[] {
0x52, 0x00, 0x11,
0x52, 0x01, 0x11,
0x52, 0x02, 0x11,
0x52, 0x03, 0x11,
0x52, 0x04, 0x11,
0x52, 0x05, 0x11,
0x52, 0x06, 0x11,
0x52, 0x07, 0x11,
0x52, 0x08, 0x11,
0x52, 0x09, 0x11,
0x52, 0x0A, 0x11,
0x52, 0x0B, 0x11,
0x52, 0x0C, 0x11
};
serialport.Write(toWrite, 0, toWrite.Length);
#endregion write
//dmc 270607 changed back to 100 ms not 50ms
delay(200); // wait for 100ms
// Read the Serial Port, and store the results in the appropriate key object.
string failureMessages = key[remoteKeyNumber].storeReading(readSerialPort(100, currentSerialPort), remoteKeyNumber, cycleNumber, buttonNumber);
I must now assume that The micro controlelr decoding the data is sent the HEX information from the C# program. Reception of the HEX we get the information I need. Which explains why I can't see anything on the port.
Can someone explain to me why it is an array of bytes? Can't be send ACSII or something? Becasue the data coming back is read in an array of bytes as well.
Can this be done in LabVIEW?
// Read the Serial Port, and store the results in the appropriate key object.
string failureMessages = key[remoteKeyNumber].storeReading(readSerialPort(100, currentSerialPort), remoteKeyNumber, cycleNumber, buttonNumber);
//======================================
if (loadCellcheck.Checked)
{
// write tp log file
logfile.WriteLine(
cycleNumber + "," + keyNum.ToString() + "," + buttonNumber + "," + temperature + "," +
Enum.Format(typeof(RemoteKey.dummybyte), key[remoteKeyNumber].Header(remoteKeyNumber), "x") + "," +
key[remoteKeyNumber].FixedCode(remoteKeyNumber) + "," +
key[remoteKeyNumber].ButtonData(remoteKeyNumber) + "," +
Enum.Format(typeof(RemoteKey.dummybyte), key[remoteKeyNumber].HoldCounter(remoteKeyNumber), "x") + "," +
key[remoteKeyNumber].LastRollingCodeString(remoteKeyNumber) + "," +
key[remoteKeyNumber].LastRollingCode(remoteKeyNumber) + "," +
" " + "," +
" " + "," +
Enum.Format(typeof(RemoteKey.dummybyte), key[remoteKeyNumber].CustomerCode(remoteKeyNumber), "x") + "," +
Enum.Format(typeof(RemoteKey.dummybyte), key[remoteKeyNumber].Checksum(remoteKeyNumber), "x") + "," +
" " + "," + " " + " ," + " " + " ," + " " + " ," + res_reed + " ," + pressMeasured.ToString());//+ "," + newVoltage.ToString()); // +
}
09-11-2011 08:14 PM
I'm confused. Are you having problems with that microcontroller C code, or problems with LabVIEW. What is the "key object" you are talking about?
Have you looked at the serial port examples in the LabVIEW help?
09-11-2011 08:44 PM - edited 09-11-2011 08:48 PM
There is only one data type you can send over the serial port - a byte. It can actually be from five to eight bits but we will call it a byte because for one that is what you will get from VISA reads and second that is by far the most common. But VISA returns a string you say. A string is simply a... "string" of what? Yes that's it - bytes. ASCII and HEX are not data types. They are interpretations of binary data. Hex is a numbering system and ASCII is a mapping of byte values to characters. So whatever your microcontroller is sending is going to be a string of bytes. What those bytes mean is something that LabVIEW does not know.
What is being returned to LabVIEW? Something you can do is to wire the output of the read to a string indicator. Set the string display format to hex if you see either garbage or nothing at all.
09-11-2011 11:44 PM
Hey Guys,
Sorry for the confusion.
Product(carkey) >> Microcontroller >> PC (LabView)
The original program used to retrieve the data from the Micro was written in C# - With no documentation what so ever.
I am attempting to do the same (and then some) in LabVIEW. The PC controlled a process to test the product.
Instead of using C# I want to do it in LabView because I find it a lot better.
Thanks for the HELP!!!
K
09-12-2011 09:25 AM
@Kamilan wrote:
I must now assume that The micro controlelr decoding the data is sent the HEX information from the C# program. Reception of the HEX we get the information I need. Which explains why I can't see anything on the port.
Can someone explain to me why it is an array of bytes? Can't be send ACSII or something? Becasue the data coming back is read in an array of bytes as well.
Can this be done in LabVIEW?
Steve already explained that the serial port is simply dealing with binary data and thius data is defined in units called bytes. The key to your problem is understanding what bytes you will be getting and how they should be interpretted. LabVIEW is capable of dealing with virtually anything.
Based on your description the communication with the microcontroller appears to be a simple command/response protocol. The array in the C# code are the commands sent to the microcontroller and these commands are in binary. The reason I say this is that the commands contain unprintable characters so they are not simple ASCII strings. (An ASCII string would be a human readable command such as something like IDN?). The response you get to each command will be dictated by the command and the microcontroller. I imagine it will also return the data in a binary format. If you want to display this to a human you will probably need to have some code interpret the responses and format the data to be displayed. Again, you have to look at some other specification to see what the response formats are and what the individual fields mean.