06-18-2019 10:34 AM
I really think we need to take a step back. The STM32F407 is just an embedded board that you can program. So...What is the messaging protocol you have coded up in the board? Even a glimpse at the code would help a lot here. Once we understand how the microcontroller is trying to talk, we can work on getting LabVIEW to talk the same protocol.
06-18-2019 03:39 PM
I can give you the operating principle of my program:
consists of receiving numeric value (exp: 100,120,200, ... etc) these values generate (a calculation is done internally) with STM32 then the result of calculation is displayed on the interface labview.
so far my problem is solved it remains that the time between the calculator in the CPU of the card and the time of sending and received in the interface labview
as a solution: I use the for loop with N is the number of values I want to send (exp: 4) and inside the loop for utlise a numeric switch box for N = 0 we send the value E0 and display the value S0, for N = 1 send E1 and print S0, but there is a phase shift between the card execution and the for loop count in labview even if I use the same wait time in both (500 ms)
I use a USB TTL adapter for UART STM32_ PC communication
06-18-2019 03:45 PM
for the number of bits transmitted, for resolute this problem I use visa proprity node) serial setting- byte of port
06-18-2019 03:46 PM
I can give you the operating principle of my program:
consists of receiving numeric value (exp: 100,120,200, ... etc) these values generate (a calculation is done internally) with STM32 then the result of calculation is displayed on the interface labview.
so far my problem is solved it remains that the time between the calculator in the CPU of the card and the time of sending and received in the interface labview
as a solution: I use the for loop with N is the number of values I want to send (exp: 4) and inside the loop for utlise a numeric switch box for N = 0 we send the value E0 and display the value S0, for N = 1 send E1 and print S0, but there is a phase shift between the card execution and the for loop count in labview even if I use the same wait time in both (500 ms)
@crossrulz wrote:
I really think we need to take a step back. The STM32F407 is just an embedded board that you can program. So...What is the messaging protocol you have coded up in the board? Even a glimpse at the code would help a lot here. Once we understand how the microcontroller is trying to talk, we can work on getting LabVIEW to talk the same protocol.
06-18-2019 11:12 PM
@Ouni.BARGOUGUI6125 wrote:
then the result of calculation is displayed on the interface labview.
You still are not giving us the right information. What does the data look like when you send it through the serial port? Are you able to read it in a text file (implying you convert into an ASCII text)? If so, do you have a termination character to make sure the complete message was received? If you are sending binary/hex/raw data (not converting into ASCII text), how many bytes are in your measurement? How do you know you go the right bytes in a single read?
06-19-2019 04:32 AM
@crossrulz wrote:
@Ouni.BARGOUGUI6125 wrote:
then the result of calculation is displayed on the interface labview.
You still are not giving us the right information. What does the data look like when you send it through the serial port? Are you able to read it in a text file (implying you convert into an ASCII text)? If so, do you have a termination character to make sure the complete message was received? If you are sending binary/hex/raw data (not converting into ASCII text), how many bytes are in your measurement? How do you know you go the right bytes in a single read?
you can see the program running on the 32 stm card and the one running with the labview interface
06-19-2019 07:23 AM
So the LabVIEW program is to write a byte telling the controller what voltage to run at. It then does a measurement and spits that data back to the LabVIEW program. So the first thing I notice is that your set voltage is using the voltage from the previous read. You need to move the HAL_UART_Receive() to be before the HAL_DAC_SetValue(). This way you get the set value, set the value, do the measurement, and then return the measurement.
On the LabVIEW side, I would get rid of the Bytes At Port and just wire a 1 to the number of bytes to read. This will eliminate possible race conditions. Just be sure to clear the buffer before you enter your loop just to make sure nothing is left in there. This would also allow you to remove the Wait on the LabVIEW side since the loop will be throttled by the waiting for data to come back.