Rolf Kalbermatter

Input registers are a totally different entity than holding registers and the Modbus protocol uses different function codes to read them. And a third function code to write to the holding registers. The LabVIEW VIs hide this function code from the user but you have to use the correct read function to cause the correct registers to be read.

Most problems about Modbus communication are related to the different address notations that are commonly used and the fact that some are 0 based while others are 1 based. I also find the distinction between registers, holding registers, coils, and discrete inputs rather confusing. Basically discrete inputs are boolean inputs, coils are boolean outputs and registers are 16 bit inputs and holding registers are 16 bit outputs. Then there is the fact that two registers can often be used together as a 32-bit register or a 32-bit floating point number but as far as the Modbus protocol is concerned need to be treated as 2 consecutive 16-bit values. The valid address range for each of these four types is 0 - 0xFF00 But there is an alternative address writing called entity form. Here the first digit indicates the type of register (0 - coils, 1 - discrete input, 3 - input register, 4 - holding register) and the next four digits indicate the entity address which is 1 based. There are many LabVIEW libraries to do Modbus, but most of them do use the standard address and function code input. Not sure which library you exactly use, but that 256 needs some checkin. 0x200 would be 512 in decimal notation.

There is and it is called Interapplication Communication. Which one to use depends on the platform and your familiarity with a specific method. - File IO (multiplatform, trivial to setup, difficult to manage as you have to deal with concurrency of two applications trying to access the same file) - DDE (Windows only, ultra ancient and much older than legacy, don't ever use it if you can help it) - Shared memory (super high throughput, complicated to use, pretty different APIs and methods on each platform) - (D)COM (Windows only, complicated to use from anything else than C(++). - Pipes (Standard method on Unix, LabVIEW supports it on Unix platforms only, Windows has pipes too but it is a fairly obscure and seldom used feature) - TCP/IP (multiplatform, native support in LabVIEW, almost as high throughput as Shared Memory when both sides are on the same machine since the network socket uses internally shared memory to transfer the data between the two endpoints, can also work over the network where client and server are on different machines) - If both sides are LabVIEW based, you can also use the VI Server interface. That goes over TCP/IP too under the hood, but gives you a fairly easy method to directly access VIs in the other process. The TCP/IP method is by far the standard method nowadays. It is ubiquitous on pretty much every platform, from the tiny embedded controller up to super duper ultra high performance computers. It has a few minor challenges such as proper network setup, the very distinctive server/client model and if you do not want to have to configure the client and server in some ways for their IP address and port number, you need additional complicated services that let you discover the according resources on the network. Most of them do however cause more trouble than they solve, so for your home grown kitchen sink automation, the easiest is to simply leave these things configurable in an ini file or something.

Does the Patch update somehow also contain VIPM? Seeing that it is a patch it probably doesn't but it's worth checking. When you install packages through NIPM you can usually select sub packages that are or are not installed. Default is to install everything but if there is a selection possibility (the Full LabVIEW installer gives you an option to deselect VIPM), then you can control what gets really installed.

How about deselecting VIPM installation in the package when installing?

Swiss too, The Emmentaler cheese has rather big holes usually. It's the proverbial Swiss cheese, although in the US, Swiss cheese is something different. 😀

And I incidentally just had an application that I had inherited from someone and needed to debug where GetValuePointer.xnode would return with an error 7 : File Not found, when executed in a build app. Rather than digging into xnode handling and find out why on earth it was returning such an error (for a reportedly valid pointer created with DSNewPtr) I simply replaced the whole thing with a call to StrLen and MoveBlock and was done with it!

It's only for Linux 64-bit a 64-bit value. And it's seems a bit of a GCC choice, while Microsoft chose to keep long as a 32-bit integer (and not support long long for some time instead insisting in their _int64 private type). And while not sure about the original Sun Solaris versions which might only have existed as 32-bit anyways, the later Linux kernel based versions however almost certainly use the same logic as the other Linux versions, although Sun had a tendency of trying to customize it when they could, and sometimes even when they shouldn't :-).

Not likely. The efficiency in the Transpose function comes from the fact that LabVIEW really creates something that is called a sub array. This is not a real array but a data structure that contains flags, offset, stride and similar attributes and a pointer to the original array data. Many functions in LabVIEW are able to operate on both arrays and sub arrays. A transposed array simply stores the fact that the array data is actually transposed in the flags and then any function that sees it knows to exchange the row and column value in the original array. If a function doesn't support the sub array flavor it simply calls a function that converts the sub array into a real array, eventually imposing the penalty of the transpose operation anyhow, but many functions can simply work with such sub arrays directly. A graph for instance has the ability to transpose the 2D array data already, so if it receives a transposed sub array it simply inverts the transpose setting of the graph for this array data. For the indexing into the array the fact that the array is transposed should not really make a big difference as the real data is still in the original order (if it wasn't, the whole operation would not only use double the memory but be significantly slower as shuffling the data around is taking some performance).

Note that "long order" is an int32 under Windows in any bitness, but an int64 under Linux for 64-bit! And the i32 portion in v might be actually in the higher order half on Big Endian platforms. For current LabVIEW versions that is however only relevant for VxWorks RT targets. All other supported platforms are Little Endian nowadays.

There are many companies offering technologies that are based on optical fiber sensors. One I have helped in the past was FBGS in Belgium, with this software https://fbgs.com/components/illumisense-software/ .

The zero feedback is a common problem. Or if you get feedback it is often about "if you could add this and that feature, please" which feels rather "beggish" and often the "please" is even missing. Considering that the whole thing is out in the open as open source so anyone who would care can get his hands dirty and get that feature built in themselves, is quite disheartening. And extra bonus would be if the result would be shared back with the community. 😀

IMAQdx Open Camera VI accesses the IMAQdx driver API which only can recognize certain types of cameras that must themselves somehow announce to the system. For Webcam cameras this happens through the dedicated camera driver that is installed in the OS system and which installs the camera in the Windows DirectShow system which IMAQdx can access. For other Cameras it depends on the camera. Firewire cameras install in the Fireware driver stack which IMAQdx also can access. But Network cameras are an entirely different beast. IMAQdx has functionality to work with such cameras as long as they support the Genicam standard, which is part of the GigE standard (although not every GigE camera implements this properly and therefore may not be compatible with IMAQdx). Any other camera is NOT automatically supported by IMAQdx. If you want to access it in IMAQdx you have to install them as a Windows DirectShow device with an according DirectShow or kernel driver. In your case you are wanting to find most likely an RTP-UDP DirectShow driver for your camera. There are many around on the internet, most not for free, and all of them require you to setup the actual camera URL in the driver settings.

The Create Image function does a search in a list of images based on the name you pass in and automatically will reuse that image if it finds it. If not it will create it and add it to that list. The linear increase in execution time is a clear indication of this. As the number of images in this list grows, the search will take longer and it is obviously a simple linear search. Why this increase doesn't seem to happen in the IDE is a bit a mystery. Something somehow seems to cache some information here.

That's definitely true, unless your time costs nothing 😀, which it very rarely does. Maybe someone working at a university could do that, but they hardly will ever need a real Test Executive. Also if you do it as a hobby, the hours don't really count either, but for that a real Test Executive is WAYYY too big to ever hope to tackle it. Leaves the professional use cases and unless you are planning to sell your own Test Executive it almost always will be more expensive to write your own. Actually the initial writing is not even the biggest cost factor although certainly not something to ignore, but the long term maintenance is the more costly and less sexy work you have to do. If you have unique requirements such as that it runs on the real-time, developing something yourself may be unavoidable, but otherwise it is going to be simply a "not invented here syndrome".

😃 lol, missed that one.

This link doesn't work. Maybe you need to setup an alias on your website. The correct location seems to be https://www.hampel-soft.com/release-automation-tools-for-labview/

LabVIEW controls are not Windows widgets but fully created and maintained by LabVIEW itself. As such you can not locate LabVIEW controls with tools like AutoIT that assume that a user interface is based on controls that are implemented as Windows child windows. I'm not familiar with UIA, but the claim that it can identify and control LabVIEW controls does sound a bit strong to me. From what I know, LabVIEW controls are fully owner drawn and implemented using a LabVIEW internal object oriented system originally even implemented in standard C, but since almost certainly ported to a C++ system. As far as any external system is concerned a LabVIEW front panel does simply contain lines, texts and maybe some alpha shading but no controls whatsoever. The only entity that can access this object hierarchy for external applications is the VI server interface, but that is highly LabVIEW specific. So I would suppose one could develop an AutoIT plugin that goes over VI Server to control the UI of a LabVIEW VI.

Back in those days I had my own Test Executive Framework modeled around how the NI Test Executive was designed. It worked pretty well but was quite a burden to maintain. That was in LabVIEW 5.1 and 6.x days and VI server was just about invented and very limited, so quite painful to implement a system like a Test Executive that should be easily scriptable. We later moved to a system based on Lua for LabVIEW for some of these applications, where Lua was the scripting environment that the test engineer would use to customize the entire product tests. It worked fairly well but had its own challenges as many things were either integrated in the LabVIEW application and only modifiable by us but not the client, or we had to do the interfacing in Lua too and that would usually make the code so complex that the client couldn't change it either. It's a very tricky thing to get right. In fact I think there is not a single solution that fits all. TestStand went into a certain direction that works fairly well for semiconductor testing and characterization but not as ideal for some other test setups. And it is a system of its own that is fairly complex and needs to be understood well in addition to whatever extra environment you use to implement the actual test connectors (LabVIEW, LabWindows/CVI, Visual Studio VB,C/C++, or Python). Also it is quite database driven so you need to have some ideas about that too or you end up in a mess with it quickly. I never quite felt at home with TestStand, despite having it used for several customer projects, mainly in the semiconductor industry. On the other hand, writing your own Test Executive is A LOT of work, both for developing it and even much more so for maintaining it. I would not really want to do that anymore unless there would be a very unique opportunity for a specific project, but chances for that are pretty much non-existent. And inside Averna we have our own product Averna Launch which is build around NI TestStand. So chances to get to develop something else besides that are pretty much moot. 😀 Averna Launch however takes the database control to an even higher level, so you really have to think about that in order to get the maximum benefit of the product.

Well, I have a 4.3 alpha on github. But haven't been able to work on that for some time.

We also have iDeal here in the Netherlands! 😀

The unchange is in other solutions called mask. And it is in reality simply doing a read, with a boolean combined OR of the value and an AND of the mask and then writing it back.

The underlaying API does not support that and it is quite logical. I2C and SPI are not really designed as bit protocols but as byte protocols. They address typical multiples of 8 or 16 bit per data transfer. The method to do what you want to do involves reading back the full 8 bit port, modify the bit in question and send back everything.

Well you installed the 32-bit version of the the DLL (syswow64 is despite its name NOT for 64-bit DLLs but the 32-bit versions of DLLs on a 64-bit Windows system). Same accounts possibly for the MPSEE.DLL. They all need to be 64-bit in order to be loadable in 64-bit LabVIEW! Best is probably to download the actual MPSEE driver directly from the FTDI site here and use the 64-bit version of the DLL inside under: libMPSSE.zip\libMPSSE__0.6\lib\windows\visualstudio\x64\Release\libMPSEE.dll