ShaunR

Nope. I can't use anything that I didn't write myself unless it has an explicit licence that I can adhere to . I have another solution that also supports IPv6.

Then they can't use the upper bits in a future version if they want it to work on 32 and 64 then If it was Linux, I'd be worried but M$ tend to keep backwards compatibility. I think we are talking at cross purposes, I am talking only of the FD arrays for the Select Single VI in this API but I think you are talking about the socket type generally. I just fixed the error in select to get it to work. You'd have to speak with the original developer, All my socket API's use a U64 on the compane and usz in the CFLN - which was why I fixed the select the way I did. I'm not planning on using this API so if there are more issues, then the owner should address them (otherwise there'll be hundreds of variants kicking around; each with their own buglets).

That's not what's happening here. The correct call is made in the CLFN (I love the [unsigned] pointer sized integer ) it's just that I'm using LabVIEW coercion to upscale a 32 bit array to 64 bit array in 64 bit machines where you are arguing to use LabVIEW coercion to downscale a 64 bit array to a 32 bit array in 32 bit machines. At present, it makes no difference . The only valid (but very weak) argument here is whether M$ may use the upper bits of a U64 which means, if they do, then the upper bits may no longer be zero's so you may have to change values in the array anyway (so can change it to 64 bit then) and it will no longer be able to be used on 32 bit machines. Or, like I said, they go to 128 bit or something (and keep it the upper bits unused) when your solution would be "as buggy" as my solution but both would still work. I don't have a crystal ball so will cross that bridge when I come to it.

Well. It's a choice of the original developer. Personally I don't try to second guess M$ and if it falls over after an upgrade, I'll charge to fix it You never know, they might be using 128 bit or quantum machines by then so it may be for nowt. We found a problem and came up with a solution. Our work here is done

I don't think you even need to do that. The way LV deals with 32 and 64 bit is commutative. Oh god. don't talk to me about VxWorks. I still have nightmares about that from SQLite. It's what things like this were for: static void byteReverse(unsigned char *buf, unsigned longs) { static int littleEndian = -1; if (littleEndian < 0) { /* Are we little or big endian? This method is from Harbison & Steele. */ union { long l; char c[sizeof(long)]; } u; u.l = 1; littleEndian = (u.c[0] == 1) ? 1 : 0; } if (littleEndian != 1) { unsigned int t; do { t = (unsigned int) ((unsigned) buf[3] << 8 | buf[2]) << 16 | ((unsigned) buf[1] << 8 | buf[0]); *(unsigned int *) buf = t; buf += 4; } while (--longs); } } Good riddance, IMO

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