ShaunR

Many moons ago we were using the NI 32 channel digital input and output cards (now no longer available). These boards could sink a couple of amps per channel and we needed at least 1.5 amps per channel. There were no other cards on the market that could sink amps (mostly a few hundred milliamps) and the lead time became 4 months. We needed 128 digital outputs and 64 digital inputs (6 cards per machine). Talking with the Electrical guy on the project he said we needed the amps so that we could activate 24v control signals directly without buying relays to intermediate (we would have needed 128 relays at about $8 a pop adding ~ $1000 unbudgeted per machine as well as the headaches of trying to mount them) and the cards were only about $300. He said he could do better in 3 weeks So he designed a 64 channel card with 32 digital in and 32 digital out that could sink 3 amps per channel. He designed each with a serial port (the NI originals were PCI cards) but I wasn't happy with that and made him put in RS485 (today I would have gone with ethernet). So we ended up with 32 channel input, 32 channel output with 1Mbit RS485 comms, able to sink 3 amps per channel. The BOM for the cards cost $30 and we got them built for $100 as prototypes-no doubt that cost would come down if we had gone into production (the electrical guy said that mass production cost would have been about $90 per card, all in). So now we only needed 4 cards and had oodles of digital inputs spare at 60% the cost of the NI cards, although we did need an NI RS485 card so it broke about even. Need more IO? Just stick another card on the bus . I wrote the firmware for the cards and a LabVIEW driver because, of course, the NI drivers were for PCI, not RS485, but there were drop-in replacement VI's and a couple of VI's that had more features that I'd always wished the NI drivers had had. FPGA's are probably a different kettle of fish, however, due to throughput But there are advantages of doing your own thing. The one thing I did learn from the exercise was, if possible, don't put cards in the computer. From that time forward I always looked for ethernet, RS495, or Profibus IO (preferably SCPI instruments where applicable) so that different manufacturers hardware could be easily swapped out-software changes because of hardware changes don't scare me. It also means you don't need the headaches that come with PCI expanders and large industrial computers as well as, pretty much care-free, mounting and wire routing with all the associated connector stress problems.

Nice and great explanation I changed the read node's readfds, writefd and exceptfds to be arrays of unsigned pointer sized integers (instead of U32 ) which should do the same from your explanation (and it's quick 'n easy ). It now works a treat From all the aggro I've had trying to get even the tiniest morsel of information out of Linux people (present company excepted, of course). I'll let them worry about it working over there.

Try here.

Was expecting something like this.

I ran the LabVIEW IDE as administrator ("run as") even though I am already a local administrator. That usually sorts those issues out (certainly worked for creating symlinks, back in the day), Select returned error -1 and the "WSA get Last error" (and "get last error") reported "0" but that's probably to be expected due to thread dependent error stacks. I vaguely remember having similar problems when not using FD_ZERO(&ReadSock); FD_SET(Socket, &ReadSock); FD_ZERO(&WriteSock); FD_SET(Socket, &WriteSock); properly before "select" when getting the socket status for normal sockets-which may or may not be relevant. Those are just macro's though so can't be called.

viSci linked to it 4 posts above.

That API doesn't work for me out-of-the-box. Fails with a nebulous error at "select". IcmpSendEcho works fine, however.

Depending on what you mean by doesn't work and "do not respect"; Problems with timeouts <500ms sounds like NAGLE to me.

There is the IcmpSendEcho. It's fairly straight forward and is a one-function call. Rolf used to have a ping library too. Not sure where that is now.

I don't have a use case for this but I love that the API uses plymorphic VI's-a vastly underused feature IMO. If you want to organise the functions instead of having a huge linear list, you can group them by separating the menu item with a colon ":".

20 years ago they were building better software. Discuss

With the help of torekp in tracking down some issues; a new version (1.0.1) is now available.

I did find a bug for 64 bit that caused mapping to fail, sometimes, in later LabVIEW versions (it's written in 2009). There will be a new version in the next couple of days that I can test with your cmd-line software so keep watching.

As an aside. Item 5 on that list is why most companies' Agile development is pants. They put all the problems in the backlog (good) then the Product Owner prioritises which ones - if any - get fed into the next cycle (bad). Companies that have a policy of addressing all the backlog issues (zero backlog policy) before working on new features in the cycle, demonstrably produce far superior code. Most companies', however, just have an ever expanding backlog and end up with tripe 10-20 iterations down the line.

Are you using LabVIEW 64 bit or 32 bit? Generally speaking, if the other program creates the mapping then you should only open it instead of creating it so it may depend on which program you are running first (you create a file mapping in that example). Note there is no option to "Open Or Create" in the LV API as you have used in the cmd prompt software. Running your command prompt software first and reading with the following works fine for me in both the dev environment and as an executable (although it's LabVIEW 2021 32 bit since I don't have 17 installed).

Well. Posting a an image of a small section of your program means we have to guess a lot but here we go. There is no "best way" to display the information but probably the easiest is as an array of clusters. modules.vi As for reading the modules, that depends on the devices but guessing that your "Code" string is a long list of module capabilities and information (one of which being the version) encoded as hex; ultimately you will probably need an array of "Code" strings instead of a single "Code" string - one element for each of the PCB's queried. It looks, from your image, like you will have to refactor. When you do, get rid of that monster "Index array Element" and use a VI to splice (see below) the needed data inside of the big case structure. That will greatly improve the readability of your code and localise transformations/calculations to the specific case. It will also enable to create sub VI's to make your code more modular because, in this particular VI, you will just be passing the Code string into the big case structure. This will help enormously when you come to iterate over an array of "Code" strings. splice string.vi

Project Manager

It depends. How do you do it on Linux and Mac?

You'll get no sympathy from me There is a reason (actually a plethora of reasons) .NET is banned form my projects The RTF bug is in the save function. You can either save it as UnicodePlainText (lose all the snazzy rendering stuff like images) or get the RTF string and save it with LV file primitives. But your problems are only just starting with the RichTextBox. Like I said. It will get you 80% of the way there.

Just to side-track the whinging completely (most of it mine ) and to show that it's not as hard as NI make it out to be; this will get you about 80% of the way with UTF8 (UTF8 FTW) on English Windows systems. Note that the Windows ANSI functions - the underlying calls for the LabVIEW primitives - do notionally support UTF8. Rolf can give a much better explanation of why this works (Codepages) and the pitfalls of using it. There is no change to the VI, by the way. It is just changing the setting and restarting the OS. utf8.zip

It's not directed at us (engineers). It's a sales pitch to internal profit centers with the hope that external LabVIEW engineers will use the arguments to their upper management. In essence it is "this is good for both of us, but mainly us, and means we will listen more, maybe". You will notice there are no concrete or tangible benefits to anyone other than NI. However I don't think this brain-wave coming directly after NXG being killed is coincidence. What is clear is that their mind is made up and now it's just a case of managing the PR. "The beatings will continue until morale improves" - Captain Bligh in Mutiny on the Bounty

Then the hard work is done. The FPGA in that project was to implement the MIPI receiver. If your camera is giving you the FPS you need, then it's just post-processing you are interested in? You are already in the analogue domain so why not just use comparators for that? They are cheap and have can have nanosecond propagation delays. Unless, of course, the image acquisition ADC is not as bare-bones as I am envisaging. Where I'm going with this, though, is to do as much as possible in hardware but I can see the attractiveness of a general purpose FPGA. I would ordinarily suggest the so called "Smart Camera's" which are excellent bang-for-buck with these kinds of requirements and have a lot of the features that LabVIEW has but your sub msec requirement prohibits most of those.

I'm not sure you will find an off-the-shelf solution to this. Sub-millisec means a frame rate over 1000fps before you get to any processing. I'm not promoting this as a solution but you may find some useful information in this little project. Opens Source IMX219 Camera MIPI CSI-2 Receiver Verilog HDL Lattice FPGA MachXO3 Raspberry PI Camera mipi_csi_receiver_FPGA I'd also be interested in hearing more about your ADC solution if you can flesh it out more thoroughly.

I wouldn't bother, personally. It seems a poor solution. If I were to point to a problem with LabVIEW errors it would be resolution and they don't help with that. I did have a whole paragraph on what I would like to see as an improvement to error reporting and how to achieve it but I reconsidered in the face of LabVIEW still considering reading an entire file as an error and AQ's presentation.

I actually took it as an utter disdain for the time and cost of working around their deficiency. The presupposition that there was a work-around and I haven't told customers that we can't do it because LabVIEW doesn't support it. That the work-around would cost x weeks of project time to achieve (to the customer's surprise when they thought it would be par-for-the course) so the customer didn't order it. Or even an entire framework based on HTML interfaces was developed relegating LabVIEW to a mere back-end service (this also goes for his "Vector UI nonsense too). I'm sure the counter-argument would be the 3rd party tools that are available for internationalisation but that just shows that he's never tried to use them in a project or been called out to a customer site when they can't load a file because the filename is Unicode or suddenly everything has turned to Chinese characters. After all. We've only been complaining about Unicode support for a decade or so, right?