Rolf Kalbermatter

Yes time is money and I like to kill some time sometimes. 😜 More specifically I have learned a lot by investigating those questions before I could post an answer or example how to solve something. As we are speaking I was actually trying to find an open hikvision camera on the net to try to do a few things. Rather than having to hack a camera, or find a hacked private one, which seems rather easy for HikVision cameras if my googling didn't fail me, I would like to have an officially open camera somewhere instead. But that proofs not so easy to find. There are several sites that list open cameras of various types that can be simply accessed but none so far seems to be a HikVision camera. Most of what I see are Panasonic, Axis, Mobitix and a few others. 😆

You don't. C# does not understand C syntax and therefore the only thing that trying to add the extcode.h header file will achieve is to create compile errors. If you want to access unmanaged APIs in C# you have to do P/Invoke and/or Marshalling. And that PostLVUserEvent function is an unmanaged API in terms of .Net. But that's not all! You need to tell the C# compiler where it can find that API by specifying the DLL it is in. However that depends on if your code is called in the LabVIEW Development system (LabVIEW EXE is exporting that function) or if you try to call your code later in a build application (lvrt.dll or possibly another DLL is exporting that function). So your C# code has to start to find out if it is called from a LabVIEW VI in the IDE or from a build LabVIEW executable!!! And that is still not all. Basically it is not feasible to try to go this route if your external wrapper DLL is written in C#, just as simple as that. Since your actual API is also not a .Net API you are starting to build a tower by mounting a stick on a beam that is balancing on a pencil and everything is kept up by strings going everywhere. Take a step back for a moment. Basically your API is a standard DLL which is unmanaged, and you could write a C(++) DLL that directly interfaces this and then use PostLVUserEvent(). Or if that proofs to intimidating to you you definitely should forget about PostLVUserEvent(). Instead write a real .Net assembly that exports a proper class which has a .Net event. Then interface to this .Net assembly using the LabVIEW .Net nodes. Now you can connect to this .Net event with LabVIEW functions by registering a callback VI that is called whenever that .Net event is triggered in your assembly. That's the only feasible approach if you want to stay with a .Net assembly.

And someone downloading Moon Knight in addition gives them like what? Eternal gratefulness? I know what torrents are and have played around with it's predecessor eMule a little. eMule still exists as I found out recently but its servers are mostly taken over by people who want to push things down your throat that you would never ever want to touch with a ten foot pole. I'm not sure why torrents would be that much better to be honest. 😀

Almost certainly not a PostScript file. That PS probably stands for something the developer ate that day or maybe it could be his initials or the initials of his girl friend. We likely will never know. 😀 Are you able to even receive the JPEG file yet? Remember what Shaun said. Try to walk before you run. And I would say getting the JPEG download work yourself without someone doing all the work for you is already advanced walking training. To get the Callback function to work is Marathon style running on Olympic levels. 😆

They and others have repeatedly provided installer downloads that are supposedly cracked to circumvent the serial number license check. If that is true or if they are actually modified with other less friendly hacks that may install a backdoor on your system instead, or maybe a nice cryptolocker ransomware, is always the big question. 😝 As long as they just mirror the standard offline installer image, not even NI would likely have any problems with it, but why would someone sacrifice server space and internetbandwidth on their system without wanting to get something back in return? 😀

I"m not even sure they still have USB sticks. CD's and DVD's definitely are not available anymore (with software bundle downloads with the size of 40 to 50 GB that would be also unpractical) 😀 Most likely the USB sticks sank on the way from China to the European warehouse, so there is something like a 50 weeks delivery time for them. And who said that WITH MEDIA means a physical tangible item. A download could just as much be considered media and since you have a valid SSP you should be certainly able to download it. The challenge might be to assign that serial number to your user account, especially if you are one of those who explicitly likes to never register your products with the manufacturer. Unlike most other products, where such a registration is just to collect email addresses for marketing purposes, the LabVIEW serial number registration actually makes a huge difference. 😀

No! The function mentioned will simply return a single JPEG image frame (probably only if an acquisition is running). Still it is useful to get this working first to actually get the interface at least exercised. Before you can do a Snap with this function you can do whatever acrobatics you would like but it is useless. Start with easier things and get them working, then move on to play with the dangerous tools. 😀

1) You don't, since it is not code. It is the function prototype (actually the function pointer declaration) of a function that YOU have to implement. And then you pass the name of that function as parameter to the other function that wants this callback function. Whenever that other function thinks it wants to tell YOU something it calls that callback function with the documented parameters and YOUR callback function implementation does then something with that data. But your function is called in the context of the other function at SOME time after you called the original function that you passed your callback function too. Are you still with me? If not, don't worry, most people have big trouble with that. If yes then you might have a chance to actually get this eventually solved. But don't expect to have this working tomorrow or next week. You have a steep learning curve in front of you. 2) The iCube Camera in is simply a LabVIEW class that handles the whole camera management in LabVIEW, and in some of its internal methods accesses the DLL interface, and creates the event message queue, and starts up an event handler, and ..., and ..., and .... 3) The RegEventCallback function is a LabVIEW node that you can use to register events on CERTAIN LabVIEW refnums. One of them are .Net refnums, IF the object class behind that refnum implements events. .Net events are the .Net way of doing callbacks. It is similarly complex to understand and implement but avoids a few of the more nasty problems of C callback pointers such as datatype safety. But to use that node you will need a .Net assembly that exposes some object class which supports some events of some sort. Since .Net uses typesafe interface descriptions, LabVIEW can determine the parameters that such an event has and create automatically a callback VI and connect it behind the scenes with the .Net event. It works fairly good but has a few drawbacks that can be painful during development. Once the callback VI has been registered and activated, it is locked inside LabVIEW and there are only two ways to get this VI back into an editable state. Restart LabVIEW or after the object classes on which the event occured have been properly closed (Close Reference node) you need to explicitly call the .Net Garbage Collector in LabVIEW to make .Net release the proxy caller that LabVIEW created and instantiated to translate between the .Net event and the LabVIEW callback VI. If you have a .Net assembly that exposes events for some of its object classes, it is usually quite a bit easier to interface from LabVIEW than trying to do callback pointers in a C(++) DLL/shared library. Writing an assembly in C# that implements events is also not really rocket science but definitely neither a beginners exercise. 4) If you interface to C(++) in LabVIEW there is no safety net, sturdy floor, soft cushions and a few trampolines to safe your ass from being hurt when something doesn't 100% match between what you told LabVIEW that the external code expects and what it really does expect. It's in the best case a hard crash with error message, the next best case is a hard crash with no error message and after that you are in the lands of maybes, good luck and sh*t storm. A memory corruption does not have to immediately crash your process, it could also simply overwrite your multimillion dollar experiment results without you noticing until a few hours later when the whole factory starts to blow up because it is operating on wrong data. So be warned, thread safely and make sure to have your C(++) solution tested by someone who really understands what the potential problems are, or don't use your code ever in a production environment. This is the biting in your ass that dadreamer talked about, and it is not really LabVIEW that did it, but you yourself! 5) Which video screen output are you talking about? Once you managed to get the camera data into your LabVIEW program without blowing up your lab? Well you could buy IMAQ Vision or start another project where you will need to learn a lot of new things to do it yourself. 🙂

There is a reason why so many pleas for support of camera access are out there and no single properly working solution except paid toolkits: Actually it's not one but a plethora of reason. - cameras use lots of different interfaces - they often claim to follow a certain standard but usually don't do so to the letter - there are about several dozen different communication standards that a camera manufacture can (try) to follow - it involves moving lots of data AFAP which requires good memory management from the end user application down to the camera interface through many layers of software often from different manufacturers - it costs time, time and even more time to develop - it is fairly complex and not many people have the required knowledge to do it beyond a "Look mom it keeps running without needing to hold its hands (most of the time)" Callback function are not really magic, but there is a reason they are only mentioned in the advanced section of all programming textbooks I know (if they are mentioned at all). Most people tend to have a real hard time to wrap their mind around them. It starts for many already with simple memory pointers but a call back function is simply a memory pointer on steroids. 😀 And just when you think you mastered them you will discover that you haven't really started, as concurrency and multithreading try to not only throw a wrench in your wheels but an entire steam roller.

It's a good thing. Unfortunately NI seemed to have stopped in various areas to fully implement features at the moment they got barely usable, not implementing certain fundamental things for some reason and concentrating their efforts on others that are highly specialistic and obscure. And documentation is pretty minimal to say the least.

Standard error output can't show anything either when you make the wait for completion false. So that would not indicate anything. With wait for completion set to false the process is launched and forgotten by LabVIEW. If it runs a millisecond or infinitely doesn't matter for LabVIEW. It has long continued and that process may still be running, or may have died or normally terminated. So the only thing that remains is: Does the LED toggle anyhow and does it show some progress in the command window? If so then the only difference is that with wait for completion set to true LabVIEW will wait for the process to terminate and then copy the standard output and standard error information into the string indicators of that function. With wait for completion set to false LabVIEW will NOT connect the standard input, standard output and standard errors in any way and whatever your program writes to those either is shown on the command window or lost forever in the /dev/null world of computers.

That's almost like asking if you can install a GM engine into a Toyota. 😀 Answer is yes you can if you are able to rework the chassis, and make just about a few thousand other modifications. But don't expect support from either of the two if you ran into a snag. More seriously, you may also run into license issues.

Don't try to install drivers! They typically contain kernel components and Rosetta 2 is not able to emulate x64 code in kernel space. This was a conscious decision by Apple, as trying to support that would likely have turned Rosetta 2 development into a never ending crashing story.

How do you determine that your script is working? As you don't wait for completion, the error cluster obviously can't indicate anything about the actual execution of the command, only if LabVIEW was able to create the main process.

That depends VERY much on what PXI controller you want to do that. https://www.ni.com/nl-nl/support/documentation/compatibility/17/real-time-controllers-and-real-time-operating-system-compatibili.html# Only the PXI-8821, 8840 and 8880 were Pharlap ETS systems that have NI Linux RT support available. And it may be something that has to be factory installed, but I'm not sure about that.

You need to understand what Managed code means. In .Net that is a very clear and well defined term and has huge implications. LabVEW is a fully managed environment too and all the same basic rules apply. C on the other hand is completely unmanaged. Who owns a pointer and who is allowed to do anything with it, even reading from it, and when, is completely up to contracts that each API designer defines himself. And if you as caller don't adhere to that contract to the letter, no matter how brain damaged or undocumented it is, you are in VERY DEEEEEEEP trouble. LabVIEW (and .Net and (D)COM and others like it) all have a very well defined management contract. Well defined doesn't necessarily mean that it is simple to understand, or that there are lengthy documentations that detail everything about it in detail. Not even .Net has an exhaustive documentation. Much of it is based on some basic rules and a set of APIs to use to guarantee that the management of memory objects is fully consistent and protected throughout the lifetime of each of those objects. Mixing and matching those ideas between each environment is a guaranteed recipe for disaster. Not understanding them as you pass around data is that too! For other platforms such a Linux and MacOSX there also exist certain management rules and they are typically specific to the used API or group of API. For instance it makes a huge difference if you use old (and mostly depreciated) Carbon APIs or modern Cocoa APIs. They share some common concepts and some of its data types are even transferable between those two without invoking costly environmental conversions, but at that point stops the common base. Linux is according to its heritage a collection of very differing ideas and concepts. Each API tends to follow its own specific rules. Much of it is very logical, once you understand the principles of safe and managed memory. Until then it all looks like incomprehensible magic and you are much better off to stay away from trying to optimize memory copies and such things to squeeze out a little more performance. One of the strengths of LabVIEW is that it is very difficult to make code that crashes your program. That is until you venture into accessing external code. Once you do that your program is VERY likely to crash randomly or not so randomly, unless you fully understand all the implications and intricacies of working that way. The pointer from a LabVIEW array or string, passed to the Call Library Node, only is guaranteed to exist for the time your function runs. Once your function returns control back to LabVIEW it reserves the right to reallocate, resize, delete, or reuse that memory buffer for anything it deems necessary. This part is VERY important to allow LabVIEW to optimize memory copies of large buffers. If you want to have a buffer that you can control yourself you have to allocate it yourself explicitly and pass its reference around to wherever it is needed. But do not expect LabVIEW to deallocate it for you. As far as LabVIEW is concerned it does not know that that variable is a memory buffer, nor when it is not anymore needed or which heap management routines it should use to properly deallocate it. And don't expect it to be able to directly dereference the data in that buffer to display it in a graph for instance. As far as LabVIEW is concerned, that buffer is simply a scalar integer that is nothing more than a magic number that could mean how many kilometers the moon is away or how many seconds exist in the universes life, or how many atoms fit in a cup of tea or anything else you fancy. Or you pass the native LabVIEW buffer handle into the Call Library Node and use the LabVIEW memory manager functions if you have to resize or deallocate them. That way you can use LabVIEW buffers and adhere to the LabVIEW management contract. But it means that that part of your external code can only run when called from LabVIEW. Other environments do not know about these memory management functions and consequently can not provide compatible memory buffers to pass into your functions. And definitely don't ever store such handles somewhere in your external code to access them asynchronously from elsewhere once your function has returned control to LabVIEW. That handle is only guaranteed to exist for the duration of your function call as mentioned above. LabVIEW remains in control of it and will do with it whatever it pleases once you return control from your function call to the LabVIEW diagram. It could reuse it for something entirely different and your asynchronous access will destroy its contents or it could simply deallocate it and your asynchonous access will reach into nirvana and send your LabVIEW process into "An Access Violation has occurred in your program. Save any data you may need and restart the program! Do it now, don't wait and don't linger, your computer may start to blow up otherwise!" 😀 And yes, one more advice. Once you start to deal with external code anywhere and in anyway, don't come here or on the NI forum and ask why your program crashes or starts to behave very strange and if there was a known LabVIEW bug causing this. Chances are about 99.25678% that the reason for that behaviour is your external code or the interface you created for it with Call Library Nodes. If your external code tries to be fancy and deals with memory buffers, that chance increases with several magnitudes! So be warned! In that case you are doing something fundamentally wrong. Python is notoriously slow, due to its interpreted nature and the concept of everything is an object. There are no native arrays as this is represented as a list of objects. To get around that numpy uses wrapper objects around external managed memory buffers that allow consecutive representations of arrays in one single memory object and fast indexing into them. That allows numpy routines to be relatively fast when operating on arrays. Without that, any array like manipulation tends to be dog slow. LabVIEW is fully compiled and uses many optimizations that let it beat Python performance with hands tied on its back. If your code runs so much slower in LabVIEW, you have obviously done something wrong and not just tied its hands on its back but gagged and hogtied it too. Things that can cause this are for instance Build Array nodes inside large loops if we talk about LabVIEW diagram code and bad external code management if you pass large arrays between LabVIEW and your external code. But the experiments you show in your post may be interesting exercises but definitely go astray in trying to solve such issues.

Yes and acquisitions like DasyLab, MCC and some others clearly fall into the category of buying out competition. Lookout, Electronic Workbench and HiQ are a bit a different sort of story. They were bought to buy knowhow and specific market presence and were for some time actively supported and improved by NI. But then they discovered that they could not compete with the big guys in those markets unless they would be willing to really invest lots and lots of money. And I don't mean a few millions but for each of them a real significant junk of the entire budget that NI had for the whole operation. The other problem was that most of the NI sales people had pretty much no idea about what they really were and consequently couldn't sell them very effectively. Their natural instinct was to point at LabVIEW whenever someone came with an inquiry, even if one of these packages would have fit the customer much better. I think it's unfortunate for each of those three. They were very unique in some ways and would have deserved a more active supportive development by their owner. Electronics Workbench had a dominant role in the educational market by the time NI bought it but is nowadays nothing more than an anecdote in the history of electronic design and development tools. That's for a big part thanks to NI's inactivity and disinterest in it. But if NI hadn't bought it it probably would have ended up as another product of Autodesk or similar, that would sort of market it but really try to nudge the user with soft force into moving to their main product instead. And nothing much would have changed. 😀 Lookout wasn't the biggest player in the market by far but its architecture was very clean and very unique and not encumbered by countless legacy hacks from other SCADA packages that existed in the market since when DOS was the main operating system for them. HiQ was more like Mathematica than Matlab in many ways but still different enough to deserve an independent existence. Of those three only Matlab remains as still a surviving product. Digilent would seem to be again a somewhat different story. I can not see where they possibly could have been a significant competition to NI nor what NI was really expecting from it. I think that it was more acquired as a pretty unfinished idea to create a stronger educational presence and then the market analysts came and killed that idea. MCC in the new NI also clearly isn't any competition anymore to anything they do. Rather it could serve as the entity that combines all the remains of old NI and some of the brands that still have some promises and haven't faltered beyond the possibility of reanimation.

They own Digilent, MCC (and with it Data Translation) and a few other companies that all work in that segment. So yes it would make sense to combine that all into a new independent company and make it self supporting. So far they didn't seem to do much with it. It almost feels like it was mostly about buying up competition than any specific long term strategy to build something out of it.

LabVIEW never has been a money maker for NI directly. They were able to develop LabVIEW because of what they earned with their hardware sales. And LabVIEW was used to drive those hardware sales. A very successful model that drove others like HP Vee and such out of the market in the not very long term. Maybe HP/Agilent also was simply already to big for that market segment that they could possibly target with a product like this. The entire T&M component market isn't that huge. For HP it was what they had been starting with, but the big money was earned (and sometimes biggly lost) already in other areas. T&M was good for a steady revenue, but nothing that would stand out on the yearly shareholders report. It was unsexy for non-technicals and rather boring. That was one of the big reasons to separate HP into multiple companies. An attempt to create smaller entities that target a specific market segment and could be fine tuned in the sales and marketing efforts to the needs of that market. About 10 years ago NI reached the size where they started to feel the limitations of the T&M component market themselves. There simply was not a big enough market left that they could capture, to continue their standard double digits yearly sales grow for much longer. Some analysts were hired to look into this and their recommendations were pretty clear. Don't try to be the wholesale everything for all little parts manufacturer in T&M, but concentrate on specific areas where big corporations with huge production lines invest their test and measurement money. Their choice fell on semiconductor testing and more recently the EV market. It has a huge potential and rather than selling ten-thousends of DAQ boxes to hundreds of integrators, they now sell and deliver hundreds of fully assembled turnkey testers to those corporate users and earn with each of them more than they could ever earn with several 1000 DAQ boxes. What used to be NI's core business is nowadays a side line, at best a means to deliver some parts for those testers. But more and more a burden that costs a lot of money in comparison to the revenue it could even under ideal conditions generate. If you can understand this you also can guess where NI is heading. They won't die and their shares will likely not falter. But what they will be has little to do with what they used to be. If LabVIEW still has a place in this I do not know. Personally I think it would be better if it was under the parapluie of a completely separate entity than the new NI but I also have my doubts that that would have long term surviving chances. Earning enough money with a development environments itself is a feat that almost nobody has successfully managed for a longer period. But the sometimes heard request to Open Source LabVIEW has also not a lot of chances. It would likely cause a few people to take a peek at it and then quickly loose interest, since its code base is simply to complex. And there is also the problem that the current LabVIEW source code never could be open sourced as is. There are so many patent encumbered parts in it and 3rd party license dependencies, that nobody would be legally allowed to distribute even a single build of it without first hiring an entire law firm to settle those issues. While NI owns the rights for them or acquired a license to use them, many of these licenses do not give NI the right to simply let others use them as they wish. So open sourcing LabVIEW would be a fairly big investment in time and effort before it could be done. And who is willing to foot that bill?

Are you referring to scripting? It still is there and is called Transaction Start and End.

No I haven't but according to this page there are a number of possibilities. - ODBC driver This should be possible to be accessed with the LabVIEW Database Connectivity Toolkit with very little problems. - SQL API This is a REST API. As such it could be used with the HTTP Client VIs in LabVIEW. However it will require some work of your own to write wrapper functions around the desired API endpoints that take data and format it into JSON to send as HTTP request and then decode the response from JSON into actual data.

You need to translate them. There may be a service in the PLC that lets you translate names to addresses but I have no experience with Omron PLCs. For Beckhoff PLCs it is possible to retrieve a list of variables that enumerate all variables with their name and list the actual register address where they are stored. Lacking that you need to refer to the W227E12 FINS document and locate your type of PLC in there. There is a Memory Area Designation for each model series that tells you how the CIO, TR, G, A, AR, CNT etc registers map to memory addresses. And then from your ladder logic you have to determine what specific register address a variable may have, and then translate that to a linear memory address and then use the FINS "MEMORY_AREA_READ" and "FINS_MEMORY_AREA_WRITE" commands to get that information. The library on the github site is a bit strange as it packs all the TCP/IP handling into a LV 2 style global. That makes the whole a bit complicated to use and won't allow for instance two parallel connections to two different PLCs. It would have been a lot better to actually create LabVIEW classes that keep the connection related information in the class wire. That would allow to implement a layered approach where you have a basic class that implements the actual FINS protocol (pretty much what this library is) and also provides empty overwrite templates for actually writing and reading to registers by their type and offset and then implement for each PLC type a small child class that translates the register type into an actual linear memory address for that PLC type.

This project may be interesting. It talks directly the Omron proprietary FINS protocol: https://github.com/jmor2000/LV-OMRON-FINS No OPC, no special Ethernet/IP function block or whatever needed on the Omron PLC. While the Omron FINS protocol is proprietary it is actually openly documented by Omron: https://www.myomron.com/downloads/1.Manuals/Networks/W227E12_FINS_Commands_Reference_Manual.pdf

Technically it is all passed around by pointer, which is synonymous to by reference. Logically that makes no difference whatsoever as it all happens under the hood. Data going into a subVI through the connector into a control is consumed by that subVI and considered to be private to the VI. If LabVIEW needs that data somewhere else, it will make a copy, but it has optimizing measures in place that may schedule different functions consuming the same data in a way that they can not stomp on each others data. Data coming through an indicator out of a subVI is from that point owned by the caller and the VI better doesn't try to change it after the fact. For LabVIEW VIs that is not a possibility at all as LabVIEW takes care of that. For data returned from external code through a Call Library Node, it is a grave violation of the LabVIEW memory management contract to try to modify the data in the background once the Call Library Node call has returned control to the diagram. LabVIEW is a managed environment just like .Net but has different management rules. As far as LabVIEW diagrams are concerned there is virtually no way to violate those rules since the dataflow determines everything. If you interface to external code then you could violate that management contract in the external code but doing so is equivalent to placing a bomb in your PC! 💣

You were to fast. I typed a wrong URL 😀