Tim_S

Have you looked through this document?

There is a significant amount of the population that has some amount of colorblindness. It's not a bad idea to take screenshots of your UI and then convert the image to greyscale.

I was looking at UEI products many years ago, but never had a project could use them on. At the time the PCI cards were very similar specs to NI at less cost, but the front end didn't appear to be as robust. They also had a 'cube' product where it was stackable boards on a base module; it looked interesting, but again didn't have a project that it would work on. Got a sister division that uses Beckoff remote I/O. The sampling rates would be slower. Recall the prices were pretty good for remote I/O systems when tried to get a feel for the product.

Well, yes and no and yes and maybe. It all depends on what you're trying to measure and what the system requirements are. And, of course, just because it's cheaper up front doesn't mean it's cheaper overall. If it costs $200 less but takes me 50 hours longer to implement then it costs more.

Been trying to pick up Python and getting continuous DAQ has been part of that. Found where someone created a continuous DAQ with displaying the data on a graph using pyqt. Link is https://github.com/toastytato/DAQ_Interface.

NI has published their hardware lifecycle policy. When you look up each of the controllers you can see what the current lifecycle status is. Below is a search for the part number on NI's website.

I take it you don't have a dedicated connection between the two devices. Things that can break the system that come to mind is the routing and if there are duplicate IP addresses on the network.

I've used them in that way pre-maps leveraging variant attributes. Don't expect JSONtext to handle that use case, though.

Don't forget versions, updates and patches, particularly in operating systems. For example... had a customer call me with a station that was down after a couple years of running. It looked like a UDP communication issue between two PCs. Wireshark showed the UDP message showing up at the port, but the application didn't receive it. Eventually this was tracked down to the build of Windows 7 (1609, if I recall right) can randomly turn off a setting that UDP needed to work. The "fix" involved a registry edit, but it's waiting to happen again.

The least painful way managed to do this was to detect the column header was clicked on then change the background color of the header appropriately. It's not great, but users understood what was going on once they were shown it.

I have to say no for applied knowledge. I think should be aware of when it is advantageous and inappropriate to use OOP, but that falls short of applied knowledge.

Not familiar enough with Linux or ZeroMQ to give a specific answer, but thinking this through... Segmentation fault is the program trying to access memory it's not supposed to. Certainly been able to do that on Windows, so I don't see why can't do the same with Linux. Typically get that when working with drivers, which ZeroMQ would qualify as. Could be something like passing a pointer that is or becomes invalid, or trying to access memory that has been freed up.

The site is doing a sales pitch on it's front page. That's fine all sites do that. I'm already a customer so I go to the NI site for 1) product information, 2) support, or 3) downloads. It took me poking about a bit to find what was looking for as the navigation feels almost hidden up top. Now that I've got an idea of how the layout has changed I think I'm OK and it might be more navigable. Just got to ignore everything past the top inch of main page and all should be good.

Something the "supplied cables" reminded me of is that APC UPS (at least the ones I've been using) use a non-standard pinout on the DB9 for serial communication. The UPS comes with a cable with the correct pinout on each end. Any chance that's what's causing grief?

Should HID start testing your sanity... Tripplite has a relay card

Your Keyence representative should be able to help if you can't get it from the website. I've been in contact with multiple over the last few weeks, so I expect you would be able to get a response today.

Don't know if this will work with your design, but... I have a similar situation of class reference to itself. The code is the base object for plugins and gets compiled into a packed library. The class has a vit inside of it that the child uses to create a version that it sets in a property. The property is strictly typed to the vit and gets called by the parent. To make this work I had to put a control of the reference in the library the parent class is in. This is the way I was able to get around a reference to a class within itself.

The only time I consistently use Defer Panel Updates is with a TreeView control, which is slow to update the display (particularly when creating hundreds of rows). Another strategy is to check for data change to see if an update is needed. But, really, it depends on what you're doing. A configuration/editing screen is driven by user actions, so one event trips multiple updates to the UI and Defer Panel Updates can be useful. A screen showing periodic data may update each message with no issues, or checks if anything needs to be updated and when it does may need to defer updates to do so quickly. Though if you have something like an informational/debug screen that is only shown when requested then might not update the front panel unless it's visible. Could put that as you've done the cost-benefit analysis and the improvement is not justified.

Looks like all the PYNQ boards are programmable in Python. There was a question on NI Community about this.

Working fine in 2015 (latest I've got installed).

I don't have the vision addon installed, so can't point you to a specific VI. I recall there being an example that performed a histogram of the colors (in RGB?). You may need to open up various vision examples as it might not specifically state it was a histogram example.

I think you're looking for annotations.

Stopped having that issue once went to using win32 calls to make window frontmost and always on top (which has created new issues). Seems like would either hide the window while the file dialog was running or make the VI not modal while the file dialog was called.

Fortran 77 still was taught in at least one college in 1993 on green-and-black and amber-and-black terminals. Was even a mandatory class for freshmen.

I've gotten a test bench of 1 MS/sec of 32-bit data (24-bits plus 8-bits channel identifier) across FPGA->RT->Windows using DMA channel to RT FIFO to TCP and let it run overnight without drop of any data. Buffer was set to maximum size of U32. Now that was with a cRIO rather than a myRIO. Are you using NI's recommendations for best practices? Particularly the one where you check for available (request 0 samples) and then read all is a good way to read on the RT side. If you wait until the buffer is full then the FPGA can (and almost certainly will) overwrite before host side can service an interrupt.