LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Control Values not Transferred into Event Structure

Hi All,
 
1.  I used Event Structure to call up different VI's performing different function on the same serial port.  The serial port controll settings are outside of the event structure, please see the attached file.  My problem is the settings for the serial port are not transferred to the VI's inside the event structure on the first call.  For example, if I selected the port as COM2, on the first call of the "Modbus MSG" VI inside the event structure, the VI will open up with default port COM1.  Close the event (Modbus MSG VI) and call it up again, this time the port will show as COM2.
 
2.  The Modbus Serial Init VI (from NI Modbus Lib.) has Stop Bits set at 1, and does not have control on its front panel.  For Modbus Spec, Even parity requires 2 Stop Bits.  My problem is regardless whether Stop Bits is set at 1 or 2, I still get the correct response messages from the Modbus device.  Changing the number of Stop Bits in the MB Serial Init VI or in the LV MAX comport settings seems to make no differences.
 
Do you know the reasons?  I appreciate your opinions.
 
TT
Download All
0 Kudos
Message 1 of 6
(3,060 Views)
Your event structure will be one update behing because the controls are read and then the event structure sits and waits for an event to occur.  So the values have been read, and any changes made to those values will not be read until an event occurs and the loop runs another iteration.

You can either wire a timeout value to the event structure, which will cause the loop to continue to run if an event doesn't fire (and therefore re-read the control values), or you can create empty events for each of the 4 controls, just so the loop will iterate only when one of those values changes.

You should also combine your two event structures together.
Message 2 of 6
(3,051 Views)

Matthew,

Thanks for your help.  I have not try the time-out event yet but creating empty event for the controls eliminated the problem with the event structure.

As for the number of Stop Bits with Even Parity issue, I'm still searching for a reason.

TT

0 Kudos
Message 3 of 6
(3,034 Views)
Hey ttsd,
From what I've read up on modbus for serial communications, even and odd parity only require one stop bit. If you use the No Parity configuration you will need two stop bits, in which case the extra stop bit just replaces the parity completion bit. I found this resource to be really useful: Modbus for Serial. 12/44 is the page that specifically references the part about even and no parity items

Hope this helps
Can Wong
0 Kudos
Message 4 of 6
(2,995 Views)

Hi Can,

I am aware of the modbus requirements.  The thing I observed is that the number of Stop Bits is irrelevant.  As long as you have other serial parameters setup correctly, different number of Stop Bits doesn't matter.  My thinking was that the UART will need to see Start Bit, Data Bits, and Stop Bit to recognize and decode a character.  Whether 1, 1.5, or 2 Stop Bits, it is just the idle time before the next Start Bit of the next character frame.  If the idle time is less than 3.5 character times, it is not the end of the message and communication is still normal.  The purpose of Modbus requirement of 2 Stop Bits in No Parity mode is to make sure there is enough idle time between character frames; if necessary, the host master will have enough idle time to perform other function before processing the next character.   Thanks.

TT

0 Kudos
Message 5 of 6
(2,992 Views)
Hey ttsd,
Yes, as long as everything is set up correctly, the stop bits should default to 1. If No Parity is set up, there may be a need to change the stop bit, but that depends on different factors.

Can Wong
0 Kudos
Message 6 of 6
(2,951 Views)