ShaunR

Doesn't VIPM check the dependencies before installing or can't you check for the dependencies in the pre-install.vi?

Well. Assuming you have enabled the bridge (last line of the troubleshooting in the manual) have you tried adding the alias manually?

Don't you mean "wire by wire"? Generally, VI's are functions so you could write the same functions but the contents would be completely different. Many functions just wouldn't be relevant because of the way LabVIEW works - especially if they are to control the UI. Then it also depends on what you are going to write the new code in. Delphi UI's are, for example, event driven so you are in a completely different paradigm. If you have architected your program then you can transfer the architecture but you are still moving to a different paradigm (from data-flow). A lot of the LabVIEW support (drivers etc) come with other language bindings, so the really hard stuff such as DAQ and VISA etc wouldn't be too bad. Personally, I would do (and have done) a complete rewrite and change all the things I didn't like about the old program-if push came to shove. Saying that, though, you would be better off replacing parts, piecemeal, with DLL's until there is no LabVIEW left. I was in a position where I could do a complete rewrite (ah, Waterfall development ) At least then you can reuse the DLL's at the very least. If you also create DLL's from LabVIEW code, you can integrate them into the new, non LabVIEW software and then replace them later with non-LabVIEW DLLs. Boy, you've had a huge black pill suppository, haven't you

In addition to JKSH comments, You are using an express VI which are known to be slow. What is the throughput do you require? How much data are you trying to save (every second, every minute)? A typical mechanical hard disk will be able to cope with about 50-100MB/sec. A decent SSD 200MB/sec at least. The Win 32 File IO is much faster than the native LabVIEW. The link contains examples including queue buffered which JKSH commented on.

If you can't see it in MAX then it's not your code. Have you followed the troubleshooting guide in the manual? https://www.ni.com/pdf/manuals/375250b.pdf Is it an MXI controller?

While that may be true to a greater or lesser extent. Stack Overflow will close the thread so you can't give more details, ask more probing questions or help them in any way. What it means is that Google search is littered with dead ends.

I wouldn't know. The only time I ever go over there is when there is a link from here

I don't see what all this fuss is about, to be honest. Lavag isn't a company requiring growth for shareholders. Everyone is welcome, of course, but I don't really care if it's just an old-boys network of 20 people. Answers to my questions come from here and never from NI - neither their support of forums. Don't forget that Lava stands for "LabVIEW Advanced Virtual Architects". They are a dieing breed so it's no wonder there are fewer around. If you want to know how to use LabVIEW then it's better over at NI. If you want to discuss (or argue about ) methodologies and concepts; Lavag is the place. As regards Stack Overflow and Reddit - give me a break, Reddit is a hell-hole of politics and Stack Overflow is full of stuck-up people who would rather chastise you for how you formulated your question.

There's not much. Some useful functions are documented (Moveblock, for example) There is a file (extcode.h) which has many of the function prototypes which is located in the cintools directory. That and tribal knowledge about C and LabVIEW equivalence is usually what people use. Rolf knows a lot (I mean everything) about the underlying, opaque, structures used by LabVIEW but for most of the functions, C knowledge and extcode.h is usually all we have.

Antoine's new profile pic is enough to scare anyone off of the forums-including search engines. He's really let himself go.

It stops at 2018. all the stuff you listed is on the FTP site for 2017 just search the page for, wait for it, "2017"

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.