extracting data from a 18byte data packet

[RavensFan]

---

@Yush wrote:


Another thing I don't fully grasp is what happens when I choose to run the VI continously. Does it just cycle through the entire piece of code over and over from start to finish?

---

NEVER use the run continuously button.  If a VI is designed to run only once like yours is, it will repeat is over and over again doing all the commands in order as set up by the dataflow.  So it will repeatedly open and configure the serial port.  This could cause you to lose data.

You should only use the run button.  Set up initialization/configuration code in front.  Have that feed into a while loop where you continuously read the serially port and work on the results.  That while loop should have a Stop button control that wires to the stop terminal of the loop.  So the loop will run until you hit the Stop button control that will appear on your front panel.  When the loop finishes executing, that will lead into the code where you close your serial port and open files.

---

@Yush wrote:


Also, one thing I noticed in your code tbd was that none of the resource name outs of the visa write blocks were connected to the visa read resource name in node. Should I be doing that as well? (Right now I have connected the resource name out of the 'start' section to the resource name in of the serial read)

---

The way tbd wired up the VISA wires is okay, but it is not the usual way of doing it.  Usually the VISA out of one function will lead right to the VISA in of the next.  It saves making extra copies in memory of that value (don't worry about that), but the biggest advantage is that it makes the wiring neater by keeping everything in line.  Just make sure you wire the VISA wire straight through the false case of those case structures.

[Yush]

The error message that comes up is as follows:

Error -1073807202 occurred at Property Node in VISA Configure Serial Port (Instr).vi->CastPacket.vi

This error code is undefined. No one has provided a description for this code, or you might have wired a number that is not an error code to the error code input.

[Dennis_Knutson]

That error is common and could have been found doing a forum search. It means " A code library required by VISA could not be located or loaded." The cause for the error is not having NI-VISA installed. NI-VISA is on the drivers CD that came with LabVIEW. You can also download it. The latest is here.

[RavensFan]

Well you have only 2 things going on at Configure Serial Port.  Setting the Enable termination character to False (seems simple enough), and setting the baud rate to 38400.  That is an unusual baud rate.  Are you sure your serial port supports that rate?  Try another baud rate such as 9600.  (Even if the device you are connecting to isn't set for that, at least you'll know something if the error message changes or goes away).  Also double check that the value is truly wired to the baud rate connector and not one of the other connectors on that side of the configure serial port.

Message Edited by Ravens Fan on 09-28-2007 12:09 AM

I just read Dennis' message and I think that is a more likely option.  I set a sample VI and set my baud rate to 38400 and no errors were raised.  The one question I have for Dennis is that if NI-VISA wasn't installed, would those VI's still show up in the Labview pallettes?

Message Edited by Ravens Fan on 09-28-2007 12:12 AM

[tbd]

Hi RF,

      I've given the wire-through technique a lot of thought since first noticing it show-up as a "trend" in NIs VIs.  I think it's a bad idea in most situations - one exception being when wiring-through prmitives that aren't inside cases.

---

Ravens Fan wrote:

It saves making extra copies in memory of that value...

---

Are you saying that a "branching" wire implies a copy of the value?  I didn't know this - can you point me to some NI documentation?  Note that when the wire-through technique is carried through sub-VIs, not only do the wire "branches" reappear, but also terminals that would be unecessary otherwise.  

---

... the biggest advantage is that it makes the wiring neater by keeping everything in line.

---

It makes the caller's code "prettier" - often at the expense of additional wires.  Wires are dependencies.  Fewer dependencies => more reliable/maintainable code.

---

Just make sure you wire the VISA wire straight through the false case of those case structures.

---

That's exactly what I mean - when buying-into the wire-through technique "just make sure you wire..." those extra wires, or else your code is broken.

In addition to adding complexity, the "wire-through" technique tends to mislead the programmer.  When a VI outputs a value, it's logical to assume it's a product of the VI?  Why would a SubVI be made more complex in order to return exactly the same value already present on the caller's diagram?  The person who wrote NIs "Directory to tree.vi" made this mistake and added a bunch of wires and shift-registers to maintain a reference a value that couldn't change.  We hired a contract programmer (an EE) who did the same thing all over a huge app.

---

The way tbd wired up the VISA wires is okay, but it is not the usual way of doing it.

---

I'll agree with you there.

Cheers!

Message Edited by tbd on 09-27-2007 11:12 PM

[Dennis_Knutson]

---

I just read Dennis' message and I think that is a more likely option.  I set a sample VI and set my baud rate to 38400 and no errors were raised.  The one question I have for Dennis is that if NI-VISA wasn't installed, would those VI's still show up in the Labview pallettes?

---

The VIs are always on the palette - even without VISA installed. That's a little odd, I admit. The other odd thing is that the error messages associated with VISA aren't present until you install VISA. That's why the op got 'this error code is undefined'. If this one error code was included with the regular LabVIEW error codes, there would be a lot fewer questions to this forum.

[RavensFan]

---

@tbd wrote:

Are you saying that a "branching" wire implies a copy of the value?  I didn't know this - can you point me to some NI documentation?  Note that when the wire-through technique is carried through sub-VIs, not only do the wire "branches" reappear, but also terminals that would be unecessary otherwise. 

---

Hi tbd.

I had read about data copies and branched wires in the forums in a few places.  Here is one link I found related to it.

http://forums.ni.com/ni/board/message?board.id=170&message.id=241338#M241338

This is actually about arrays.  And of course large arrays are going to eat up memory a lot faster than extra copies of a VISA reference would.  I bet the reference would only take up a handful of bytes for each copy and I don't thing there would be any practical problem with that.   If it works for you, keep doing it your way.  If I'm wrong, and there is a real problem with that, I'm sure one of the more expert programmers will chime in.

[tbd]

Hi RF,

      Thanks for the link!

      In general, the wire-through requires extra memory and time (to return the passed-through value), so I'm not sure the memory-concern is valid even if a few bytes actually mattered.  

---

If I'm wrong...

---

I don't think you're wrong about data-copies, but if you're promoting general use of the wire-through technique that's probably a matter of preference ( - and I prefer code with less wires. -)

Cheers!

Message Edited by tbd on 09-28-2007 12:01 AM

[tbd]

... Just an additional bit re: copies:

Came across this quote (here) and thought it deserved a mention (in case of any doubts created by my silly question).

"LabVIEW uses dataflow syntax. A node in a diagram operates on its inputs and, for the most part, operates only on those inputs, without affecting the values on other wires elsewhere in the diagram. When a wire forks, its value is duplicated."

I bow to Ravens Fan's accuracy (and much better memory -)

Cheers.

[RavensFan]

Thanks, tbd.

Like I said earlier, I don't think there are any practical issues with a few extra copies of the VISA reference as they can't take up many bytes.  I knew I had read it several times in the forum in some in depth discussions.  It is really more memory rather than accuracy.   To be honest, I really don't understand why that would be the case.  If the wire is a variable, (it carries a value which means it must take up some space in memory), why does it make a copy if the branch forks going into more than one node on the diagram?  Why wouldn't each location that needs it just reference the same memory location?

On the other hand, if the nodes operate on some wires in place (say like +1, if it just adds one to the variable in the same memory location and the wire after the node references the same memory location) then it would make sense that a copy of that memory location would be needed if the wire branches ahead of the node.  Basically the difference between two lines such as x=x+1 vs. y = x+1.  I'm sure tst or someone else has a better grasp on the underpinnings of Labview as to what is going on. 

I guess since Labview and its dataflow model means that things work in sequence, that a value is maintained in the same memory location no matter how many sequential operations are performed on it.  And the occasional few brances need copies of the data, would be more efficient than making a new variable memory location for each wire between sequential operations.  Just my hunch.

-Bill