FieldPoint Family

cancel
Showing results for 
Search instead for 
Did you mean: 

Embedded_Serial_Publisher.vi

I have a question about the VI posted in this forum here by Aaron G on 6/16/04.  (If link doesn't work just search for this VI name).  It's regarding the publish command on a fieldpoint RT controller that's connected to a RS-232 device.
 
The COM1_in is shown as a "write" item and the COM1_out as a "read" item.  I believe this is backwards.  I think that outside the loop the "Create Read/Write Item" should be "Create Read-only Item" and vice-versa; as well as inside the loop the "Write Item" and "Read Item" should be switched.  Can you please confirm?  Or am I not understanding the read/write terminology correctly?
 
Thanks,
Hosehead
0 Kudos
Message 1 of 8
(4,348 Views)
Hosehead,

I have explored the example and I believe it is correct.  Each action type of the Publish Data VI has a unique behavior and some are not initially intuitive.  The timeout value also can vary the behavior of the VI.  I would take a look at LabVIEW help for this VI and compare the different actions behaviors.  If I am reading the VI correctly, I believe it is doing what it is supposed to.  I did not however try to deploy the VI.  If you have more questions let me know.

Regards,

Neil S.
Applications Engineer
National Instruments

Message Edited by Neil S. on 07-19-2006 10:30 PM

0 Kudos
Message 2 of 8
(4,335 Views)
Hi Neil,
 
Isn't the purpose of this VI to get a value from the item "COM1_in", write it to the serial port, read a value from the serial port, and send it to the item "COM1_out"? 
 
The way it is written the VI overwrites the item's value with "COM1_in" and then waits for it to be updated and sends that new value to the serial port via the 'VISA Write' command, then reads a value from the serial port via the 'VISA Read' command, then this value is wired to a Publish Data.vi that where it is immediately over-written with the "COM1_out" item's value via the "Read" configuration.  I agree that the first part will function the same as if you put a Read command on the Publish Data.vi (although IMHO it would be more intuitive to use the Read command).  However the second part will never be able to update the "COM1_out" item with the value from the serial port.  I really don't understand how this meets the purpose of the VI.
 
This is why I say I think they are reversed.  And if they are reversed inside the loop they are reversed during the creation outside the loop as well.
 
Hosehead
0 Kudos
Message 3 of 8
(4,326 Views)

Hi,

I also believe that the logic of the VI is correct. The program does not write out data from on the serial port on the FieldPoint module until it establishes that data has been changed at the COM 1 in. I recommend taking a look at the detailed context help of the Publish Data.VI for more information.

Regards,
Hal L.

0 Kudos
Message 4 of 8
(4,308 Views)

Thanks for trying to explain it.  I guess I'm dumb as a rock today because I just don't see where the item "COM1_out" is ever written to.  I've been looking at the help files for this VI but don't see anything that indicates the Publish.vi in the Read configuration will ever write to the item: "If action is read item (default action) and the item exists, the VI waits for the specified timeout period [in this case 0] for the value to be changed from the value wired in at input value, and returns the result in output value."  I don't see any writing to COM1_out going on here.

Sorry, and thanks for your patience.

H.

0 Kudos
Message 5 of 8
(4,306 Views)
Hosehead,

Are you unable to get these VIs working? I think one of two things is true:

1.) the only operation which makes sense from the embedded side on an already-created read-only item is to update it (the action input is ignored). By not wiring a timeout, the default of 0 is used and the item is immediately updated.

2.) this VI is incorrect and the read should actually be a write. By not wiring a timeout, we do not wait for the host to read the data, but rather return to waiting for more data (in the next loop iteration).

Hope this helps,

Ryan Verret
Product Marketing Engineer
Signal Generators
National Instruments
0 Kudos
Message 6 of 8
(4,278 Views)
Hi Ryan,
 
Thanks for the input.  I don't think your (1) is correct because I don't think the ITEM will be updated in a timeout - it's Read-only.  Only the OUTPUT of the VI will be changed.  But that's not the same as the item.  So as you said the only thing left is that it's supposed to be a Write.  That's good because it confirms my understanding of how these things work and means that the VI I am writing, using this as an example, will function properly.
 
I notice Aaron G is still active in this forum, perhaps he could contribute his thoughts since he's the one that wrote this?
 
Hosehead 
0 Kudos
Message 7 of 8
(4,272 Views)
Hosehead,

"If action is create read-only item and item does not exist, the item is created with read-only privileges for subscribers, and given an initial value of the value wired in at input value. Note that read-only items are read-only to subscribers, but this VI may change them by wiring in the block and item name and writing to them. The VI then waits for the specified timeout period for the value to be changed, and returns the result in output value."

This would tend to indicate that this should be a "write" action. I agree with you.

Regards,

Ryan Verret
Product Marketing Engineer
Signal Generators
National Instruments
Message 8 of 8
(4,257 Views)