jacobson

I don't think it's always better to use the FPGA over DAQmx. I think the FPGA can be very useful if you need to do some sort of inline processing/scaling, some custom triggering scheme, or if you want to do some closed loop control completely outside of the CPU, but if you're just going to be constantly streaming data to file (basically a headless data logger) then DAQmx would be my choice. One way of looking at it is if your FPGA code is just going to be a passthrough then you probably should just be using DAQmx. For the communication scheme, we would need to know more about how you're going to be interacting with the cRIO. That said, I would probably avoid having the cRIO act as a Modbus slave unless your host application is the master for other Modbus slave devices and you want to treat the cRIO the same as your other slave devices.

When I had a customer run into this problem they would have a DAbort "Couldn't create 24 pen" in drawmgr.cpp and before that were a ton of "GetDC failed in ISetGPort" DWarns coming from image.cpp (like 15+ DWarns in the 2 seconds before the crash, some within milliseconds of each other).

We've done Sunday meet ups at Banger's before, I'd be up for that again (lots of outside seating).

I guess that rules out MATLAB too.

My first thought would be why even think about building your own solution if you haven't explored the existing alternatives. I only did some minor tests with Francois' API but the client seemed to work well in both Windows and Linux so if you built your own API and posted it to LAVA the first question I would probably ask is why I would want to choose your API over the one I already was using. I think you have to spend some time evaluating existing APIs so you can have a set of reasons as to why you're building yet another API. Even if you have reasons for not liking an existing API it might still be a good use of time to see if you can address those issues by working from the existing API. As an example, if you find that the performance isn't good enough in pure LabVIEW you might not need to start from scratch. If you can get a big performance boost by replacing a few key internal VIs with DLL calls maybe you can bring that to the owner of the existing API and see if that's a change they would make. If they're unwilling to make those changes (maybe they find value in keeping everything in pure LabVIEW) then you can start working on your own API with very clear reasons as to why someone would even want to use it.

On the FPGA side, reading 2 U32s or 8 U8s shouldn't make a difference from a throughput sense. Some old info I found internally basically said that if they don't have the same throughput it's a bug. I also don't think the DMA throughput should be effected. If I remember correctly, the DMA engine will try to send multiple data items up at the same time to minimize the overhead of PCIe packet headers.

I mean stock perfectly reflect the underlying value of the company right? It seems like $53 is a premium my any measurement but they do conveniently hide that when they offered $48 per share it was below the 12-month price target for NATI (pretty sure I have my timelines right).

https://www.emerson.com/en-us/news/2023/emerson-national-instruments-announcement Although all of this is through the lens of the group that wants to purchase NI so it's not surprising they don't think NI is being reasonable (though that may be true).

So when you start your "Modal" VI you'll just set the FP.Behavior to Modal and set it back to Default when the VI finishes executing? I never thought of doing that but seems worth doing it to prevent ready to run modal windows forcing me kill LabVIEW.

I've seen a few RT applications that use move blocks over type casting as well. Obviously not very safe but it is fast.

Software is being modified by both NI and third-party so I think it would be safe to assume that LabVIEW is included under the umbrella of "NI software".

In past years there was often a meetup at some random bar on the Sunday night before NIWeek to get some drinks and hang out. Anyone know if there are similar plans in motion this year? If not, does anyone want to meet up somewhere Sunday night?

If you're working for a larger customer they also might have brand guidelines that you can follow. A long time ago I worked with someone from UT Austin and just followed their published branding material. https://brand.utexas.edu/identity/color/

For more general data acquisition systems I'll hear about UEI, VTI, Dewetron, and HBM. Beckhoff comes up plenty but the remote I/O or industrial control space does lead to them having different strengths/weaknesses.

The question below that seems to indicate that there may not be a call for presentations because they'll just pull from previously accepted sessions but who knows. Hopefully there will be good technical presentations still.