shoneill

Separate out the external Queue from the internal one. If the internal queue has elements in it, ignore the external queue. Only read an element from the external queue when the internal is empty. You can extend this to N layers by maintaining a stack of queues, where element zero is the external queue (should never be destroyed). All internal states which enque further states do so on a newly-created internal queue and pushes all other queues down the stack. This way you get deterministic execution of your states. Guaranteed execution order without interruption and a way of investigating the execution flow (depth of stack and so on). Of course when an internal Queue is empty, it is destroyed and the top-most queue is retrieved from the stack. I keep coming back to the definition of a "Pushdown Automaton" even though it really does not fit, but it helps me to visualise what's going on. Imagine that the input tape and the stack are the same thing. Each input tape is an element of the stack. Pushing and popping input tapes allows you to essentially create subroutines.

Nice. Never heard of that one before. Fits nicely.

Maybe it's a new version of the Marshmallow test.

It would be nice to have a changelog accessible before having to download the installer first.... All I see is a critical patch link, but this doesn't look like a changelog to me at all. Have I missed something?

BTW, the ability to connect a NULL reference is intended. This way, you can switch off certain events by modifying the Event Registration Refnum entries with NULL values. I have code where I register for certain events outside of a loop with exclusively NULL references, only to have a different event actually deliver the correct event references to listen to. This way the Event registration refnum is created at initialisation but remains essentially inactive until "primed".

Why would there be a coercion dot on the input of a function whose name implies it is being used for a coercion? The fact that a coercion is taking place is obvious due to the presence of the node for doing the coercion...... That aside, I think the addition of type safety would be a welcome additional function. But does your function allow us to coerce a U8 to a U16 for example? Here no data is lost and it should be completely safe (under the assumption the programmer knows what they are doing).

Hmm, maybe the manual "Save As..." and the Programmatic "Save As..." are not equivalent? Or memory fails me. I thought it wasn't neccessary to replace the controls if doing a manual "Save As...".

which is basically just automating what I said above..... Do you really need to change the controls? When you do a Save As from LV, it changes the type of the controls for you.....

Right-click the Default class in project and choose "Save As...", then create an unopened copy. You only need to rename the terminaly, but there's a quick drop shortcut available for that somewhere (rename labels). You need to manually change inheritance.

A Class knows only it's parent, not it's grandparent before being instantiated. Dynamic loading of classes prevents knowing this beforehand.

Ah, so you need 250kHz throughput, not 4us latency. Then why on earth was the 4us so prominent in the earlier posts..... anyway..... Yes, given an maximum allowed latency, parallel processing over several FFT processes will help you get to where you need to be. Just keep track of the resource utilisation of the FFT cores. It seems like the Radix-4 burst IO version allows 10 channels of 16-bit resolution with a base clock of 250MHz and a latency of approx. 26us. Streaming allows only one channel, so I don't know how well that's going to work out for you.... I have no experience with the FFP IPCore. (except what i have just tried in order to get the information listed above).

1. LabVIEW 64-bit has no effect whatsoever on FPGA performance because FPGA is not 32-bit or 64-bit, only the development environment. So sorry, but LV 64-bit brings absolutely nothing to the table. 2. Nowhere in this Xilinx document do I see a Virtex 5 doing a 2k FFT in anywhere near 4us (more like 30us). This also assuming a max clock rate of up to 425 MHz, which NI cards will not do, 320MHz is tops. I know from experience. I work with a 95T on a daily basis. 3. No, datatypes on FPGA can be from 1 bit to N bits. No real restriction. 4. I have the feeling your expertise and ability to discuss this topic is very limited because you seem to have so little understanding of the numbers behind the claims of a 2k FFT in 4us on 10 year old hardware. 5.Get the NI systems engineer to do your work for you and see how far he gets. Sounds like he's talking through his hat.

I recently tried out 2018 having worked with 2015 for the last few years. I liked the performance (even in a VM). I would be happy to migrate. Especially FPGA simulation has gotten a lot more stable. We have been unable to simulate our actual FPGA code in 2015 (spitting out random "something went wrong" errors about contacting NI with no particularly useful extra information -ugh-) for a while now, but works a charm in 2018. Ps especially since I'm using "unofficial" vims, the official support for those is a great boon of course.

Aah, private. No Problem, time to edit my INI file. Thx.

I wanted to create a shortcut menu entry for finding a VI / sub-VI in the current project context but I can't find any methods to help me accomplish such a thing. I can get the current project context, but is there even a way to control what is selected? Or to highlight an entry in the tree?

Ive only got three more videos to get. Roll on tomorrow

Actually no, seems unreachable again.

yeah, but banned again..... I don't know how to configure Firefox to limit the connections and Filezilla doesn't want to work... complains about invalid directory listing. I just download 4 files a day..... yawn.

Yes, thought it was just me. Also 323_Casey Lamers_Understanding Decoupling of Messaging in Actor Framework.mp4 crashes at 39.02.

VI window title says "Exercise" so you need to finish the code yourself.... it's not supposed to be a working VI until you actually do some work. It's to help you learn.

I'm pretty sure that's a good indicator, but not foolproof. I've had LabVIEW "idling" for nearly an hour, frozen, and come "back from the dead" afterwards. I've also had LabVIEW be "active" and not recover even after leaving it carry on for a whole weekend. Maybe if I had let is continue for just 5 minutes more, it would have completed...... I've grown to expect all kinds of weird behaviour from LV over the years. That's not meant as a compliment. I suppose we need considerably more feedback regarding what LabVIEW is actually doing so that we can better judge whether stopping the process or just waiting is the best option.

Does LV freeze or crash? I often see "freezes" of more than one hour when LV starts compiling our entire project when just moving the files to a new path on disk. If I wait long enough, it does eventually recover, but at that point it's hard to differentiate between this and "normal" LV crashes where it just sits there and does nothing and will never recover. I say "normal" because it happens quite a lot. LV 2015 SP1.

Every time I try to download videos my IP gets banned..... Only got 8 of them before lights out....

Ah yes, I remember this now, I "abused" this when doing some USB programming of my own to install LibUSB drivers for a given device on one port, and standard NI-USB drivers on another port for testing. In order to change driver, all I had to do was switch USB port instead of constantly uninstalling and re-installing. It was a nice trick (in XP at the time), I don't know if it still works with Windows 10.

No problem, no hostility detected. Honestly. Also none implied at all. I just noticed that the focus of my answer wasn't explained properly. Your "oops" while acknowledged, is not neccessary at all. Nothing whatsoever to apologise for. Although I knew my post was only focussing on the "multiple devices" issue, I simply didn't convey that properly. My bad. I only realised it after your post.