LabVIEW
CoAP Client for LabVIEW?
Calm down everybody. If anyone is willing or able to provide his VIs is their own decision. Even if you initially asked for help and then develop your own solution.
So asking for a ready (or not) made library is ok but expecting that it is also posted is quite a different story. Reasons not to post are many:
-You work for an employer and the VIs are part of your normal work: He legally owns your work and needs to be fine with you posting his property.
- The library works for your specific problem but is rather limited, hacky or otherwise not to feel proud about: Posting it either gets no reactions, which feels unsatisfactory, or bad reactions from entitled users who feel everything should be provided free of charge and in perfect functioning condition, implementing all obscure features too. Or they want to use it, but have not even basic knowledge and keep pestering you with basic questions about your library.
- You spend hours of work and don’t feel like giving that away for free.
- You developed it as part of a project for a client that was on the base that the customer pays for the whole development fully and in exchange gets full rights on the source code. In that case you don’t own the VIs anymore and need permission from that client to use them anywhere else, including posting them here.
Each of these reason is perfectly valid.
Can you please point out your submissions to the community that you posted so far, that shows that you are not just expecting others to post their work but also do your own part in providing the fruits of your work to others?
Depends what you mean with import.
Generally importing any code into native LabVIEW VIs is not really an option.
Calling other code is definitely an option though.
- precompiled shared libraries can be called with the Call Library Node, Python code can be compiled into shared libraries with the right tools, but I'm not sure why anyone would want to do that.
- .Net assemblies (for .Net Framework, not yet .Net Core) can be called with the LabVIEW .Net functions
- Python code can be called through the new Python Node in LabVIEW 2020 and newer. It requires an installed and supported Python system on the computer, to which the Python script is handed down for execution
- Matlab code can the called through the Matlab Script Node and also requires an installed Matlab system on the machine.
- Lua code can be called through Lua for LabVIEW
- There are a lot of other options like that
So there are definitely many options to use other programming languages. But I wouldn't call any of them importing the code into LabVIEW.
@Martin_Sokolov wrote:
So, how to fix this CoAP problem?
Is the best option to combine HTTP + UDP?
My idea is to send sensor data to cloud via different protocols (HTTP, MQTT, CoAP...) and to compare the delay.
Can someone help me with that?
All of these protocols are in principle TCP/IP and/or UDP based and could be implemented natively in LabVIEW. I did that in a long ago past for HTTP and that even worked, but it is quite an effort nowadays (my implementation was pre HTTP 1.0 times). The other two are not that different to implement but each is quite an effort to do from scratch. CoAP being a lightweight protocol for resource constrained devices would seem simple enough to actually implement in such a way. But you may have to get your own hands dirty and do the work yourself. Basic MQTT shouldn’t be very hard to implement either but a fully functional protocol stack can get very challenging. HTTP is similar, to just contact a web server for simple GET calls is fairly easy, but a fully functioning HTTP stack is very complicated.
If I would have to do it for a real project I would likely use binary shared libraries such as libcurl (HTTP), libmqtt and libcoap and call them with the Call Library Node. But Call Library Nodes are not everyones hobby and can be challenging to use if you are not a seasoned C programmer.
The more easy approach if you only need to support Windows would be to find out a relevant .Net assembly for each protocol and interface to it with the LabVIEW .Net Nodes.
For MQTT there exist actually some libraries for LabVIEW that are freely available and interface to one of the several open source shared libraries.
The HTTP Client VIs are under the hood based on libcurl and work for most use cases. Unfortunately NI completely shielded the entire libcurl interface behind a wrapper of their own. If the library works for you that is good. If it doesn’t because your device uses non standard HTTP methods or some other involved HTTP speciality, there is no chance to hack it into this library yourself.
