Neil Pate

As I said, weird... 🙄

Have you tried any kind of dependency checker? This can be useful in tracking down why a DLL is not getting loaded with LabVIEW. https://github.com/lucasg/Dependencies Now, I have come across one super weird issue last year which totally surprised me. I don't think this is the same thing you are experiencing, but see this thread for an explanation https://forums.ni.com/t5/LabVIEW/error-loading-lvanlys-dll-in-Labview-64-bits/td-p/4009772

I don't actually have the right toolkits installed on my PC so I cannot completely look If you right click on one of these things, do you get any kind of dialogue box that allows you to configure anything?

For what it is worth, I have never found debugging an executable to be useful. It might work ok for trivial examples but just seems to not be useful for real applications. YMMV...

What FPGA card are you using? Can you share your project and VIs? One thing to point out, I would be a little surprised if you can get 1 MHz from your timed loop on the PC. However, this is not your problem though as it would manifest as a not quite perfect sine wave on the output and would not explain a phase shift.

I think you need to start with a simpler example. (And sorry I mistakenly thought you were using RT, you are using an FPGA card in a PC, right?) Try and make the most simple scenario you can think of. A simple VI generating a single point of the triangle wave at a time. Transfer this value to the FPGA but wire this to all the analogue outputs at the same time. If you still have a phase shift then something really weird is going on. It has been a while since I used a PC based FPGA card, is is possible the FPGA analogue outputs have different configuration somehow in the .lvproj? Like perhaps different filters or something?

I suspect the problem might be you are essentially trying to do single point output from the RT side of things. The property node on the RT might look like it is doing everything at once, but I don't think it actually does update all the values as the same time. Normally you would generate a waveform by either doing all the maths on the FPGA itself or using a DMA FIFO or something similar. If you are determined to do the signal generation on the RT then try replace your 8 controls that you are using to send the points to the FPGA with a single cluster of 8 elements. This will guarantee the "atomic" transmission and might fix your phase shift.

Better check your sense of humour detector, I think it might be faulty.

I believe this now referred to as "Agile" 😉 But in all seriousness, not attempting something for fear of failure is not something I have ever really worried about. Also, it is pretty much impossible to fail on 100% hobby/pet-project/learning experience.

I think what Thomas meant is that if you are going to use Dynamic Dispatch (DD) then you are forced to have the same data type as the connector pane of the concrete DD VIs all have to be identical. If you already have something working its probably ok. As an example you cannot have Instrument 1 return an array of DBL and Instrument 2 return an array of SGL for a "Read.vi".

Hey Rob (UncleFungus🤣🤣) I actually moved away from that library in the end as I have my own actor style so wanted something more low level. I now cannot find my old code that was working with this library. I now use the MQTT library from daq.io as it gives me the low level access I need. Looking at your screenshot though I think I remember. Just at the bottom you have the cluster with User Name. I am pretty sure the private key string (as copied directly out of Azure) goes there or in one of the elements of that cluster. Now, in my production system I have moved away from this technique and am generating a SAS token each time I connect. This might be the wrong thing to do, I have no idea actually but it seems to work!

Thank you. I will try and get some more info on exactly what is required.

I have some information from one of my customers but it's a bit muddled and I am trying to understand it. As it has been described to me, a USB stick is used to "download" LabVIEW and use it as an "operating system". So obviously there is a bit of a mismatch of vocabulary here or understanding of what LabVIEW is, the closest ideas I have is that this is some kind of Linux Live USB or perhaps running the LabVIEW application directly off the memory stick without installing the RTE. Does anyone know if it is possible to run a LabVIEW application without installing the RTE by carefully placing certain files in the right place?

Ok cool, I will pick it up again. 🙂 Stupidly I am now thinking of moving the game logic to python as this will give me a chance to play with the python integration node in LabVIEW (assuming it is not too slow) and also polish up my python. The intention is that I can modify it while the game is running.

Toying with the idea of dusting this off. Is anyone interested in this?

That sounds like a fantastic opportunity, I am sure you will smash it out the park. To infinity and beyond!

I normally place a small transparent decoration over the control and this fixes it. Especially useful for tables where you are updating a reasonable amount of text.

RAM is virtually free these days. As much as I love and absolutely strive for efficiency there is just no point in sweating about several MB of memory. There is no silver bullet, if I need to do multiple things with a piece of data it is often so much easier to just make a copy and forget about it after that (so multiple Queues, multiple consumers of a User Event, whatever). It is not uncommon for a PC to have 32 GB of RAM, and even assuming we are using only 32 bit Windows that still means nearly 3 GB of RAM available for your application which is actually an insane amount.

No need to apologise, it did not come across like that at all. There is no rule that says you have to update your entire GUI every time a big chunk of data comes in. Its perfectly ok to have the GUI consumer react to the "data in" type event and then just ignore it if its not sensible to process. Assuming your GUI draw routines are pretty fast then its just about finding the sweet spot of updating the GUI at a sensible rate but being able to get back to processing (maybe ignoring!) the next incoming chunk. That said, I normally just update the whole GUI though! I try and aim for about 10 Hz update rate, so things like DAQ or DMA FIFO reads chugging along at 10 Hz and this effectively forms a metronome for everything. I have done some work on a VST with a data rate around 100 MS/s for multiple channels, and I was able to pretty much plot that in close to real-time. Totally unnecessary, yes, but possible.

My consumers always (by design) run faster than the producer. At some point any architecture is going to fall over even with the biggest buffer in the world if data is building up anywhere. User Events or queues or whatever, if you need lossless data it is being "built up" somewhere.

No, not at all. My producers just publish data onto their own (self-created and managed) User Event. Consumers can choose to register for this event if they care about the information being generated. The producer has absolutely no idea who or even how many are consuming the data.

I exclusively use events for messages and data,even for super high rate data. The trick is to have multiple events so that processes can listen to just those they care about.

if you can get this all done in C++ in a few days I am mighty impressed 🙂

Well now you are really getting in the need for a proper architecture with HAL and clonable/re-entrant actors and stuff. Not something that can be easily described in a few sentences.

You don't really need to worry about performance of the GUI anyway until you are getting into real-time updating of graphs with hundreds of MB of data. Even then it can be done if you are careful.