Micro-Nuggets !!! ~~~~ Post 'em if you got 'em

[Hooovahh]

---

@McTOM wrote:

And I did consider other options and found queues the best way - I am essentially transporting binary data, not "flags".

---

Oh sorry yeah I made a few assumptions based on how I've used them in the past.  Others may have an opinion but I would say occurrences aren't deprecated.  Given the time to develop wrappers I think Queues could probably meet all of these message types, but occurrences are so simple.  Now if your needs change, and if more functionality is needed then replacing all your occurrence code with queues or notifiers could be a pain, which is probably one reason why I seldom use them.

[crossrulz]

---

@McTOM wrote:

I agree, as a CLAD I currently abuse queues for trans-VI data exchange. 😉

---

Let's clarify some things here.  Queues are AWESOME for streaming and message type communications.  But for current value (which is the point of the image in question), a queue is not so great.  It is hard to see it, but the picture's origin was using a Single Element Queue to act as a semaphore around the data.  It worked beautifully.  But in modern systems, use the Data Value Reference instead.

[Hooovahh]

You must have known this was coming.

[Broken_Arrow]

---

@Hooovahh wrote:

You must have known this was coming.

---

I'd change the Champion to just a green wire updating the indicator. Parallel processes are so 2008.

[crossrulz]

---

@Hooovahh wrote:

You must have known this was coming.

---

I'm currently (the right) half of those options, so I'm not sure how accurate this actually is.  There are plenty of other discussions out there about how globals are evil and how they should be used, so I'll abstain from that here.

[Intaris]

When moving from one computer to another and compiling the exact same FPGA code, LV has a nasty habit of appending a machine-dependent identifier at the end of every bitfile it creates.

Simply removing this identifier from the end of the bitfile name in the appropriate build spec will stop LV from doing this and guarantees the same bitfile being generated regardless ofthe PC on which it is compiled.

[crossrulz]

---

@Intaris wrote:

When moving from one computer to another and compiling the exact same FPGA code, LV has a nasty habit of appending a machine-dependent identifier at the end of every bitfile it creates.

Simply removing this identifier from the end of the bitfile name in the appropriate build spec will stop LV from doing this and guarantees the same bitfile being generated regardless ofthe PC on which it is compiled.

---

I wondered where NI made those from.  I hate those default names simply because they make no sense.  I have always renamed the bit file names in the build spec just so I would have a simple and concise file name and I actually knew what I was loading.  Now I have other reasons to do so.

[Hooovahh]

Yup same here. I may leave it the randomly generated name for a quick test, but as soon as I go to commit it to SCC I realize the goofy name and fix it.

[DhruvAcharya]

Hi, First Thank you all guys out there for helping whoever in need. This is my starting phase with LV and Forum. I learned may things from this thread.

Nugget: As I am working with Serial Port most of the time with LV, sometimes my VI exits without closing the serial port properly. Next time if you want to access same Serial Port you need to close it first. I found a shortcut for that. Go to \Labview\vi.lib\Instr\serial.llb open Close Serial Driver.vi. Enter your port number and run this VI.

[Broken_Arrow]

Welcome to the forums DhruvAcharya.

Unless you are using a very old version of LabVIEW, the VI you mentioned is part of an antiquated API, and is not necessary, except for reverse compatibility with old code.

You can simply use the VISA functions. In your case, use VISA Close. On my palette (most palettes) it's located in Instrument I/O > Serial.

Open the VI that you referred to. There's just VISA stuff inside!