01-31-2018 04:03 AM
Hi,
I'm currently working on a efficiency test bench for E-bikes. So, to measure the input power (from the cyclist), I’m using a SRM PowerMeter which is connected to an ethernet torque analysis box.
So I configured an Ethernet TCP/IP connection in NI-MAX with the box (and it works fine). But I was wondering if the string I get in my vi contain only the payload of the frame or the entire frame (Ip source dest,MAC source,Mac dest,...,payload)?
Solved! Go to Solution.
01-31-2018 04:13 AM
The TCP functions take the actual TCP data payload and the underlaying socket driver in the OS creates the TCP headers and the IP headers to put the actual Ethernet frame on the wire. Same for receiving. You do not have to worry about creating the actual IP and TCP frame headers yourself nor to try to strip them from any received data. What you see on the API level is only the actual protocol payload without any lower level headers.
01-31-2018 04:16 AM
Hi Robin,
But I was wondering if the string I get in my vi contain only the payload of the frame or the entire frame
From VISARead you get the payload of the received data packets.
What are you trying to read in your VI?
- the first 4 bytes of the received string are typecasted to an I32, which then gets converted to a hex string: why not just take a StringSubset and display in a string indicator set to hex display mode?
- the 2nd and 3rd byte are joined to a torque value
What is the expected received string? What is the data format in the string?
01-31-2018 04:36 AM
Hi,
Thanks for the answere.
Yes this is an other way to do it, I'm still a beginner in LabView, I didn't knew this method.
I normally shoud get a 10 byts value:
2 first byts= header specified by SRM (wich should be constant (0xA4 and 0XB0) and constably change in my case)
3 byts= Torque
4 byts= Cadence
rest = useless informations
I sometimes see the A4 and B0 header but at the end of the hex value...
01-31-2018 04:44 AM
Hi Robin,
I normally shoud get a 10 byts value:
2 first byts= …
Simple implementation, you still need to convert the subarrays to reasonable numbers for torque and cadence.
I sometimes see the A4 and B0 header but at the end of the hex value...
Are you sure you need to read just 10 bytes? You should read full messages instead!
When you read too less bytes you will get the messages partly from the buffer…
01-31-2018 09:28 AM
Hi GerdW,
Thanks for the answer, but the problem with your solution is that the torque is the concatenated value of the byte 2 and 3 (2=most significant byte, 3 = less significant byte). With this solution the value will not be correct. For example:
Troque in hex = 02 60 --> to decimal torque = 608
But 02 to decimal + 60 to decimal is not = 608
I should shift the first byte to get 02 00 + 60.
Hope I'm clear enough, I'm not shure I'm using the right notations as I'm learning on the job ...
Best regards,
Robin
01-31-2018 11:27 AM
Hi GerdW,
I could you check the VI I made. I have two problems:
- When I run the VI I get an error message saying: LabVIEW: One of the string parameters contains a null character. LabVIEW does not support null characters for regular expression matching.
and pointing at the match regular expression function where I remove the header from the frame. If this function doesn't support null expression, how could I filter the frame I get (only the frame starting with A4B0 are containing the torque and cadence information).
- Could you check the part where I concatenate the 2 bytes containing the torque value? Because I constantly get a torque of 0 Nm...
Thanks for the help!
Best regards,
Robin
01-31-2018 01:46 PM
Hi Robin,
Could you check the part where I concatenate the 2 bytes containing the torque value? Because I constantly get a torque of 0 Nm...
- Why do you do all this string manipulation - and why so complicated? (Why do you need to get two chars one after one independently just to append them anyway?)
- make the display mode indicator of strings visible as often as possible (see snippet), it will help you and others understanding the code…
- Above you wrote "3 bytes for torque", now you say "2 bytes for torque": what exactly do you want to read?
Suggestion: