Rolf Kalbermatter

That's not enough information to say anything specific. Error 66 simply means that the remote side decided to close the connection. That could be for many reasons such as: - Bad network setup that causes dropouts - DHCP configuration that causes a change of the network address so that the connection is not valid anymore and gets reset by the remote side - subnet address configuration mismatches - another network device trying to grab the network address used by either side of your current connection and a few dozen more possible problems including bad hardware in your computer, the remote device or some network infrastructure in between

Sorry but with some me too message and an image we can't do much. Have you read the comments in this thread? Have you studied them and tried to apply them to your situation? What debugging steps have you done so far? What is your hardware configuration including network setup? You really will have to do the debugging yourself. There is no such thing as a free lunch when debugging your own application!

For the clSerialInit you want that parameter to be a pointer sized integer, Pass: Pointer to Value. For the other function make it a Pointer sized Integer, Pass: Value. If you pass this value around through VI connector panes, always make it a (u)int64 bit integer. Don't forget to call the clSerialClose() function or whatever it is called. The clSerialInit() function allocates resources (and almost certainly opens the serial port underneath making it inaccessible for anyone else until it is closed properly). If you don't close this resource properly you would create a memory leak and likely make the port inaccessible when starting your program again.

Not without clearly stating that it was nasty. Some here posted code that was to proof that you could do nasty things. But!!! There are a few things you can do to avoid that problem: - Don't ever open a VI that you downloaded from the net by double clicking it! Instead open an empty VI and drag the VI onto its diagram. -> Autorun is disabled that way and you get the chance to look at the diagram before you decide to run it. - LabVIEW 2021 will show a dialog asking you if it is ok to start the VI when directly double clicking a VI that is configured to run when opened.

Actually I prefer people to backsave their VI when posting. Images are ok to add to a post, but they do NOT replace the real code which is needed to actually try it out and see where problems might be, and some important code settings can not be determined from just a pic.

That's fairly paranoid considering that any VI, even when running in a PPL is basically still executing inside the same process. There are a lot more things it can do that could be much more dangerous, but you have to strike a balance between security and performance. Starting to isolate each PPL completely from the rest of the system would take up a huge amount of development effort and also cause a lot of performance loss. You wouldn't like that at all! VI server has some strict limitations when it is operating across LabVIEW contexts but limiting it even inside the same context would be to restrictive and it would also mean that you have to consider the entire scripting interface in LabVIEW as very dangerous. And yes if you use PPLs they could be swapped out by an attacker. But if that is really your concern you may have a lot of other more grave trouble. Who lets such a person even have access to that computer? Why would they attempt to attack a PPL on that system when they can have the entire cake and eat it too? It's many times easier to attack DLLs, yes even with signed DLLs, and take over the entire system, than trying to hack into a PPL with its proprietary format and only get a crude control over a single LabVIEW application on that system.

I would suggest moving this into another thread. The title of this thread is about an Open Source test executive, and you clearly state that you have no plans to ever open source it.

Generally you have one top level header file that declares the main APIs and then others that declare the datatypes and lower level APIs if any. In that case you point the import library wizard to the main header file and tell it in the additional include directory control where it can find the other header files. If you really have independent header files you can create a dummy master header file that includes all the individual header files and point the wizard to that dummy file. But, as I have pointed out many times, the import library wizard can't do magic despite its name. The C headers only define the bare bone datatype interface of functions nothing else. All the semantics about proper buffer handling, memory management, correct combination of multiple functions to create a real functionality is only documented (if at all) in the prosa of the documentation for the DLL library. No wizard can interpret random prosa text to extract these semantics out of it. You as programmer have to do it. This means that the VI library created by the import library wizard is almost always just a starting point for the real work. In the best case the API is very LabVIEW unfriendly (in LabVIEW you don't worry about first allocating a large enough buffer before calling a function, that is done automatically. A C DLL knows nothing about this type of things, respectively if it does its own management you are in even more trouble to call it from any non C environment, since there is absolutely no standard about how this management should be done and only in C(++) are you able to adapt to pretty much every thinkable management contract, no matter how crazy or überengineered it is.

Unless you plan to go independent with your own company as LabVIEW consultant or something, you definitely shouldn't need to invest your own money to attend some training. An employer who finds a few days of training to expensive and unnecessary, might be not the right employer for you. People here are generally quite friendly and will gladly want to help you. There are a few conditions of course. Nobody likes free loaders or home work hustlers, so if one of them finds his way here, he might get the first time a friendly reminder that he needs to show a bit more effort himself in order to get help. In the rare case that they insist to have a right to be helped no matter what, the tone can get less friendly, although yelling I haven't noticed, it usually rather turns into completely ignoring them. To be honest I haven't really noticed yelling in the NI fora either. It's not your average youtube channel and there is some moderation too, who will often step in when things really are in danger of getting out of hand, which very rarely happened in the past. But sometimes the answer can get a bit brisk and I'm sure I have been guilty of not always using my velvet gloves with certain people on there who refuse to follow advice since they know it better.

And while GetTextExtendPoint32() itself may be fairly fast, you have to somehow, from somewhere get a HDC to use it on. And that HDC has to have the correct font selected into it, which is part of the time consuming effort the LabVIEW TTextSize() function does. And HDCs are quite precious resources, so creating one for every font you may ever use up front is not a good idea either. The HDC also has to be compatible with the target device, (but can't be the screen device itself as otherwise you globber the LabVIEW GUIs with artefacts).

The code underneath is definitely NOT thread safe. It's concerning the Text Manager, another subsystem of the LabVIEW GUI system and the entire GUI API is UI_THREAD since the Windows GDI interface, which these functions all call ultimately weren't thread safe either back then and may in various ways still not be. Windows has some very old legacy burdens that it carries with it that Microsoft tried to work around with the Windows NT GDI system but there are a few areas where you simply can't do certain things or all kind of hell breaks loose. Now I happen to know pretty much how this function is implemented (it simply calls a few other lower level undocumented LabVIEW Text Manager functions) and incidentally they are all still exported from the LabVIEW kernel too. When you use a user font it calls TNewFont() to create a font description, then it basically calls TTextSize() to calculate the Point describing the extend of the surrounding box and afterwards it calls TDisposeFont() to dispose the font again if it created it in the first place. For the predifined fonts it skips the font creation and disposal and uses preallocated fonts stored in some app internal global. So there would be a possibility to cut down on the repeated execution time of GetTextRect() call for user defined fonts by only creating the font once and storing it in some variable until you don't need it anymore. No joy however about reducing TTextSize() execution time itself. That function is pretty hairy and complex and does quite a bit of GDI calls, drawing the text into hidden display contexts, to determine its extend.

Now that's not just dreaming but fantasizing. 😀 Developing a new LabVIEW target, even if it could reuse most of the code for Windows, which I'm not sure would be the case here, is a major investment. Why would they want to do that if they already have LabVIEW NI Linux RT? And the main reason that there is no LabVIEW NI Linux RT for Desktop solution is that NI hasn't figured out (or possibly bothered to figure out) how to handle proper licensing. They do not want to enable some Chinese copycat shop to develop their own RIO hardware and sell it with the message "Just go and buy this NI software license and you are all legal". That such hardware can be developed has been proven in the past, it basically died (at least around here, maybe they sell it in tenthousends per month inside China) because such a solution did not exist and anyone using that hardware was not just operating in grey area but fully forbidden territory, with lots of legal mines in the ground.

No, but without a legal license for NI-LabVIEW Realtime Runtime and all the various NI-other software, it's a complete nogo for anything else than your home automation project.

Looks interesting. Reminds me a little of the layout principle that Java GUis have. Needs a bit getting used to when you are familiar with systems like the LabVIEW GUI where you put everything at absolute (or relative absolute) positions. And as Mikael says, those class constants are making this all look unnecessarily bulky. And they are in fact unnecessary if you build your class instantiation properly. The Class Instantiation methods should not need to be dynamic dispatch and then you can make that input optional or possibly even omit it. The control data type of your Create method already defines the class without a need for a class constant.

If performance is of no concern for you AND you don't care about licked GUIs for your apps, Python is a good option nowadays. How long that will be before there is a new kid on the block to whom everybody is catering to and declaring everything else as from yesterday, is of course always the big question. Python with it's automatic data type system is both easy to program and easy to botch a program with. And such flexibility has of course a performance cost too 😀, as every variable access needs to be verified and classified before the interpreter can perform the correct operand on it. And while you can pack large datasets in special containers to be performant, the default Python array object (list) is anything but ideal for big data crunching. Other than that I think I would stick to C/C++ for most of the things if I would abandon LabVIEW.

As far as Phar Lap ETS goes you are definitely right. Phar Lap is a dead end and has been in fact since almost 10 years. I'm sure it was one of the driving decisions for NI to push for the NI Linux RT. It's not a coincidence that that got released about one year after Interval Zero declared Phar Lap ETS as EOL. If you want to abandon LabVIEW RT altogether is of course a different question. You can certainly build your own Linux RT kernel, and implement your own automation software platform. I would expect such a project to take only a few man years, not being integrated as much as LabVIEW and being a continuous catch up race with adapting to new hardware since what was the hottest craze last year has already been declared obsolete today. It's a business model you could probably earn some money with, IF you intend to concentrate on doing just that. If it is to support your own automation projects, it will be a continuous struggle to keep it up and running and you will likely always be scratching the corner of barely get it up and running every time, with the plan in the back of your head to make it finally a real released product that you can rely on, but which will never quite happen. IMAQdx for standard Linux is not likely going to happen ever. NI is not really selling image acquisition hardware anymore. They have IMAQdx and IMAQ Vision for their Linux RT targets so that's pretty much all you likely will ever get. There seems to have been a plan for standard Linux hardware drivers both for DAQmx and IMAQdx but with the current situation I'm definitely not holding my breath for it. Also hardware drivers for Linux is a very tricky business, you either open source them completely and get them in the mainstream kernel or you are constantly fighting the Linux Gods and the Distribution Maintainers to keep your drivers running with the latest software and will never be able to make it work even on 50% of the installed Linux distributions out there. Add to that the fact that outside of servers (where automation software with DAQ and IMAQ are extremely seldom of any interests) the Linux market share is pretty small. And the majority of those who do use Linux outside of server environments are more likely to tinker for months with YouTube videos that explain often more than questionable hacks to achieve something, than pay some money for hardware and software other than their PC rig with RGB LEDs and watercooling. For a company like NI that makes this market simply VERY uninteresting as there is simply not much money to be earned but the costs are enormous.

I believe this setting should have been by default switched off and still should be. To many problems with it. If someone wants this feature (and is willing to test his application with it thoroughly on several different computers) they always can switch it on. I don't think it is currently worth the hassle.

No there isn't such a driver (that I would know off and is openly available). There might be in some closed source environment for a particular project (not LabVIEW related, Pharlap ETS was used in various embedded devices such as robot controllers, etc) that used Pharlap ETS in the past but nothing that is official. There are several problems with supporting this: 1) FTDI uses a proprietary protocol and not the official USB-CDC class profile for their devices and they have not documented it publically. You only can get it under NDA. 2) Pharlap ETS is a special system and requires special drivers written in C and you need the Pharlap ETS SDK in order for this. This was a very expensive software development suite. WAS, because Interval Zero discontinued Pharlap ETS ~2012 and since then only sells licenses to existing customers with an active support contract but doesn't accept new customers for it. Now there is an unofficial (from the point of view from FTDI) Linux Open Source driver for the FTDI standard devices (not every chip provides exactly the same FT232 protocol interface but almost all of the chips that support predominantly the RS-232, 422, or 485 modes do have the same interface) and I have in the past spend some time researching that and trying to implement it on top of VISA-USBRAW. But with the advent of Windows 7 and its requirements to use signed drivers even for a pure INF style driver like the VISA-USBRAW driver, this got pretty much useless. This signing problem doesn't exist on the Pharlap ETS system, but development and debugging there is very impractical so when Interval Zero announced the demise of Pharlap ETS, I considered this project dead too. There was both no easy platform to develop the code on as well as no useful target where this still could be helpful. All major OSes support both the USB-CDC as well as USB-FTDI devices pretty much out of the box nowadays. This includes the NI-cRIO that are based on NI Linux RT. The only two beasts that won't are the Pharlap ETS and VxWorks based NI realtime targets, both of them are in legacy state for years and getting sacked this or next year for good. So while it would be theoretically possible to write such a driver on top of NI-VISA, the effort for that is quite considerable and it's low level tinkering for sure. The cost would be enormous for just the few last Mohicans that still want to use it on an old and obsolete Pharlap ETS or VxWorks cRIO controller. As to if there is a device that can convert your USB-FTDI device back into a real RS-232 device, devices based on the FTDI chip VNC1L-1A can implement this, here is an example as a daughter board. You would have to create a carrier with an additional TTL to RS-232 converter and the according DB-9 connector for this or if you are already busy building a PCB anyhow, just integrate the VNC1L-1A chip directly on it. The most "easy" and cheap solution would be to use something like a Raspberry Pi. That can definitely talk to your FTDI device with minor tinkering of some Linux boot script in the worst case. Then you need an application on the Raspi that connects to that virtual COMM port and acts as proxy between this and an RS-232 port (or a TCP/IP socket) on the Raspi that you then can connect to from your LabVIEW Pharlap ETS program.

Correct about the LabVIEW chroot only being an issue on the Linx Targets. But several IPCs will actually work even across chroot jail borders such as good ol TCP/IP (usually my IPC of choice as it works on the same machine, across VMs, on different machines on the same subnet and with some proper setup even across the world). Even shared memory could be made to work across chroot border, but it's complicated, sensitive for correct configuration, and shared memory is difficult to interface to in any case.

Sounds like a masterpiece of engineering. Use a non-standard connector, resp. if they use the DB9 on the other device, connect its pins in a different way than standard, and then use for every new device again a different pinout. Someone must think selling custom cables is the way to earn lots of money! 😀

Would it be a lot to ask, for this library to support C++ style comments? Basically any text after // would simply be ignored until the EOL. I know that JSON strictly speaking doesn't support comments but JSON5 for instance does support those C++ style comments.

According to this link mentioned in the post before yours, you got that wrong. pin 7, 8, 9 are the serial port signals on the DB9 connector. The DB15 connector has them on pin 1, 2, 4!

Note that LabVIEW does not officially support Windows Server OS. I believe it will generally work, but ActiveX is definitely one of the areas I have my suspicions. Windows Server does quite a bit with security policies to lock the computer down for more security. ActiveX may very well be one area that is very much affected by this. Have you talked with MatLab if they fully support Windows Server editions? In any case, ActiveX needs to be installed and that also means modifications to the registry and the installer can choose if he wants to make the component available system wide or just for the current user. Your component may be such a case, or Windows Server may enforce ActiveX registration on a per user base, or maybe even disallow ActiveX installation into the Admin account without some special command line switch. We don't know and we don't generally use Windows Server. They are usually maintained by IT staff and they tend to be very unhappy about anyone wanting to install anything on "their" systems, so it basically never happens.

And how would you suppose should your client, who wants to use this library on a cRIO-9064 (just to name one of the currently still possible options which are Windows 32-bit, Windows 64-bit, Pharlap ETS, VxWorks, Linux 64-bit, MacOS X 64-bit, Linux ARM) recompile it without having access to the key? Sure with asynchronous encryption you don't have to publish your private key but then you are still again in the same boat! If you want to give a client the possibility to recompile your encrypted VIs (in order to not have to create a precompiled VI for each platform and version your clients may want to use), LabVIEW somehow has to be able to access it on their machine. And if LabVIEW can, someone with enough determination can too. Sure enough, nowadays LabVIEW could be turned into LabVIEW 365 and you could host your code on your own compile server and only sell a VI referrer to your clients. Anytime a client wants to recompile your VI, he has to contact your compile server, furnish his license number and the desired compile target and everything is easy peasy, unless of course your compile server has a blackout, your internet provider has a service interruption, or you go out of business. All very "nice advantages" of software as a service, rather than a real physical copy.

This very much depends on the used font. Not all fonts specify glyphs for all these attributes. If it doesn't, the attribute request is simply ignored and the font is drawn in the basic form. LabVIEW doesn't draw these texts, it just passes the request to Windows GDI (or Unix XWindows, or MacOS Quartz) and tells it to do its work).