All Activity
This stream auto-updates
- Today
-
Jaishankar Udhayakumar changed their profile photo
-
280081129@qq.com joined the community
-
Francismar Condor Palma joined the community
-
Ittipon Tana changed their profile photo
-
Nima Heydarzadeh joined the community
-
Wes Hunter changed their profile photo
-
Виталий Полозов changed their profile photo
- Yesterday
-
TCP_NODELAY.llb library
ShaunR replied to Mark Yedinak's topic in Remote Control, Monitoring and the Internet
Although it may be easier from the User end, it's still fundamentally a port of OpenSSL but without FIPS support. LibreSSL doesn't support TLS1.3, currently, and according to their Git it's sitting at OpenSSL 1.0.1 so it will be a while before it has TLS1.3. -
Grahit Tengshe joined the community
-
李鑫芸 joined the community
-
TCP_NODELAY.llb library
smithd replied to Mark Yedinak's topic in Remote Control, Monitoring and the Internet
libressl seems to have a better focus on stability, plus their api is much better. https://en.wikipedia.org/wiki/LibreSSL When I wrote my little tls library i wanted to avoid the dll issue so what I did was use the callback variant of the api here and here and just used the built-in labview tcp api. The callbacks are run when the library needs more data to enter or leave, so I just made the callbacks write to a queue which I then pull from to feed the labview primitives. Its a much much much nicer api than all that openssl stuff. Openssl docs make my soul cry. -
beevo joined the community
- Last week
-
Vahan Amatuni joined the community
-
FernandoAr joined the community
-
TCP_NODELAY.llb library
ShaunR replied to Mark Yedinak's topic in Remote Control, Monitoring and the Internet
I was failry well insulated (historically) by the NI libraries, from that, since all the LabVIEW versions share the same binaries. NI wanted the binaries to be backwards compatible so they compiled them with the compatibilty flag (and a couple of their own functions). At the time I ummed and ahhd about using my own binaries and took the easy route-especially because of cross platform support where you had no idea what versions of openSSL where installed in Linux distributions on a day-to-day baisis. Not to mention the ball-ache of actually compiling them. Your preference for an intermediary binary definately has the advantage here by being able to dynamically load function pointers wheras I'm pretty stuck with one function breaks everything. I've just spent 3 days trying to get OpenSSL 1.1.1 to compile. Perl? Really? I thought CMake was bad I always do things the hard way, though, because I don't want any dependencies. If you look at all the Windows tutorials they are mainly for Visual Studio (dependency on the MS Runtime). Try and find one for MingW Add to that that I want the same names for 32 and 64 bit and voila! Configure nightmare. I refuse to use a thunking DLL for a library that size that changes the ABI on a whim. But finally I got a VM set up to build it (after finding out far more than I wanted to about Perl). I'm not touching that VM ever again. It will remain a whole VM just to build one library on one OS. Those that do are being really stingy with them too. Considering the exponential increase in address space you would have thought if you rented/bought a VPS they would give you more than one IPv6 out-of-the-box. Not a chance! -
TCP_NODELAY.llb library
Rolf Kalbermatter replied to Mark Yedinak's topic in Remote Control, Monitoring and the Internet
Recently? OpenSSL does that all the time. There have been incompatible API changes all the time. Some between 0.9 and 1.0. a few more serious ones between 1.0 and 1.1 including renaming of the shared library itself to "mitigate" the version incompatibility problem. And expect some more when they go to 3.0. Wait 3.0? what happened to 2.x? 😀 And when you look at their examples they are riddled with #if OpenSSLVer <= 0968 call this API #else call this other API #endif That's definitely not going to work well unless you always can control exactly which version of OpenSSL is installed on a computer for your specific app and then you are stuck with doing all the maintenance yourself when a new version is released. I sort of managed to make the code of my library autodetect changes between 0.9 and 1.0 and adapt dynamically but definitely gave up when they started 1.1. That together with the fact that IPv6 and TLS support beyond what the LabVIEW HTTP VIs offered wasn't even any priority anywhere. Now with 1.0.2 definitely gone in obsolete mode my library wouldn't even compile properly for the time being. 😀 PS: Just recently read somewhere that IPv4 address range has been now officially depleted, so no new IPv4 address ranges can be given out anymore. This still isn't the end of the internet as many internet providers use dynamic IP address assignment and nobody should be even thinking about connecting his coffee machine or fridge directly to the internet 😂 but it definitely shows that IPv6 support by internet providers should be something they care about. But while we here in the Netherlands have one of the highest internet connectivity rates of the world, the majority of internet providers still doesn't provide a "working" IPv6 connectivity itself. You have to use tunnels to test that! -
UPDATE: I found the issue. Had to close newly opened references in "gs_getdata2d.vi" First of all, thanks for the library. I am having one issue though. After about 10 or 15 iterations, the system errors out and the error handling (including closing references) is unable to reset itself. I suspect somewhere, there is a reference that is not closing properly as when I stop the program and restart, everything works again. Here is the code i'm using for preliminary testing.
-
That is better. I'll fix it.
-
Prasanth Sivalinga changed their profile photo
-
Andranik Agajanyan changed their profile photo
-
Reason number Avagadro's Number + 1 why units annoy me..... Too many corner cases here to worry about pretty printing. I'd simplify things and simply pass the original value (not the output of the Assert Floating-Point Numeric.vim) to a Format to String function (not Fract/Exp String to Number) and use the default formatting. You'll get base units everywhere, but for debugging and something that has to be robust enough to ship, probably as good as you'll get.
-
Works nicely, except that if I input 3 lb/min, I get 22.679618 ms^-1 kg. ms is not a SI unit.
-
In fact I would strip the units only to check the type, but pass the original value into the string format. Taking it one step further, for a real floating point value with units I would cleanup the string by using SI units and then a little regex action. Complex values with units are just too far out there to worry much about so I just use the default format. Scalar To String.vim
-
TCP_NODELAY.llb library
ShaunR replied to Mark Yedinak's topic in Remote Control, Monitoring and the Internet
Yes. All it means is that I'm moving focus from the NI binaries to supplying my own. NI have usually been a couple of years behind the latest but my customers are demanding the latest (hence my questions about TLS1.3). Couple that with OpenSSL having recently made some ABI breaking changes between versions means that multi-version LabVIEW support is a little tricky if continuing with the NI binaries. So in LabVIEW 20XX you will have [probably] the long term support version of binaries and with mine you'll have the latest with backward compatibility to LabVIEW 2012. -
TCP_NODELAY.llb library
Rolf Kalbermatter replied to Mark Yedinak's topic in Remote Control, Monitoring and the Internet
You are aware that there is a LabVIEW Idea Exchange entry about SSL TLS support in LabVIEW that is since about 6 month in development. Most likely not something to appear in LabVIEW 2020 though. I was considering reviving my library but when I saw that I abandoned the idea. -
Sadly, I still have no experience with PPLs, and you'll have to ask someone else. I have no idea about palettes.
-
I am now thinking of creating PPL for a Messenger Library, that is the best solution. I remember 2 years ago you suggested: Creating a PPL and relinking VIs in existing actors to that PPL should work. However how would you approach creating the PPL that will also appear in LabVIEW palette for development (as it is now with Messenger Library)? I would like to distribute PPL to developers seamlessly without having them to dig into the PPL and look for particular VIs.
-
Hi, I have a similar case when debugging on remote sites (USA or Asia from Europe). In my case, it takes 15 to 30minutes to get the control on the remote application. I opened a thread on NI forum but the answer wasn't satifying (https://forums.ni.com/t5/LabVIEW/Slow-remote-debug/m-p/3751311). Maybe in your case would it speed up the debug process. Best regards Jean-Daniel
-
Empoy Kords changed their profile photo
-
What happens after December 31, 3000 at 4 PM though? (timestamp value 34618060800 = x80F65B000 = b100000001111011001011011000000000000)?
-
Seems to work except that it will basically strip the unit from the number, which probably should be documented. I would "expect" a "united" numeric to result in a string with the unit label appended. <OT> I had to check what "Cast Unit Bases" does, as I never used it before. The help is quite unique in its warning: Essentially, if no unit is provided (as is the case in the new Scalar to String.vim), it takes the input and drops the unit (after conversion to the SI unit). The conversion is weird, as illustrated in the attached VI (Control with unit to Cast Unit Bases): I copied the first control and changed its unit: the result after Cast Unit Bases appears the same... ????? But it also allows you to transform a value in oz/min into one in liter... assuming that you have an indicator with the proper unit to collect the output. I am kind of at a loss as to what this was designed for (turns out to be useful for the VIM, bit other than that?). </OT> Control with unit to Cast Unit Bases.vi
-
Attached modified VI is saved in LV 2018. I reordered the TSS frames to move integers and fixed point earlier in the list. Then I added Cast Base Units nodes to the floating and complex cases. And I added an Assert Type Match node to the timestamp case. Please let me know if you see further issues. If not, I'll include this in LV 2020. Scalar To String.vim
-
Well, thanks for the education. Clearly, I should've know about the double-to-timestamp behavior... the change was during my era.
-
http://www.ni.com/product-documentation/7900/en/ "LabVIEW 7.0 or earlier used a 64-bit double (DBL) to represent time, yielding 15 digits of precision. The number of seconds between 1st Jan 1904 (the timestamp Epoch or year zero) to 1st Jan 2000 is 3027456000. Representing this as a DBL would use 10 out of the 15 digits of precision. That leaves a very small resolution space to perform hardware timings using most of the resolution by simply going from 1904 to today. Representing time as a DBL was not ideal since it did not meet industry requirements."
-
This has been around for years! I think it is number of seconds since the epoch in 1970 or something like that.
-
Walid Amk changed their profile photo
-
I am authorized to use “LabVIEW 20xx” if I absolutely must differentiate... which I generally feel I must do for any sane discussion. 😉
-
Say what?! Why in the heck is that a thing?! Since I really don’t want to dig into the C++ code to find the answer, does anyone know what it means to interpret a double as a timestamp? As for the units thing... I didn’t even test that VI with units. Didn’t think of it as a test case. I’ll investigate both and make lv 2020 either send units to default (by fixing timestamp) or to double (by fixing the assert) or to their own case (if I can find a way to distinguish).
-
Link to profile photo: https://thenounproject.com/search/?q=Tomorrow&i=2496422 (tomorrow By Adrien Coquet - licensed under noun project's royalty-free license, creative commons 3 minus attribution https://creativecommons.org/licenses/by/3.0)
-
TomOrr0W changed their profile photo
-
TCP_NODELAY.llb library
ShaunR replied to Mark Yedinak's topic in Remote Control, Monitoring and the Internet
Yes. I already do all of that for TLS (using the OpenSSL bios rather than the OS. of course) but I used the LabVIEW Open. Connect and Close to keep it cross platform when obtaining the socket. Now I've replaced those with OS sockets so was looking at completeness (of the sub-library) for sockets-I already have things like Linger and TCP_Nodelay and have added open, close, listen. I know I don't really have to worry about cross platform since I've given up on Linux/Mac support in the commercial package but I do still make it all cross platform so that I can use it on them As for your Network library. I would never have written mine if you had released it . Unfortunately you added a death timer so it' was unusable when the time came for me to use SSL (and no source for the binaries which hide some functionality). I did try to encourage you to release (in that thread) it but eventually had to write my own. Knowing what I do now about openSSL, I don't blame you for not releasing it but at the time (and for a long time after including at the time of this post) it left a huge hole in capabilities that NI weren't interested in filling. -
TCP_NODELAY.llb library
Rolf Kalbermatter replied to Mark Yedinak's topic in Remote Control, Monitoring and the Internet
Depends how you implement them but to support asynchronous behaviour is a little nasty as you need to basically create a temporary structure that gets initialized on first call and then you need to call repeatedly into the shared library function to call poll() or select() to check the status of the socket and update the structure until the operation completes either because an error occured, the timeout elapsed or the requested data has been sent/received. Without that your call will be synchronous, consuming the calling LabVIEW thread and limiting potential parallelization which the native node does support out of the box. Synchronous operation is not a problem as long as you only process one or two connections at the same time but will certainly cause problems for server application or clients that need to process many seperate connections quasy parallel. Why I know that? I did the asynchronous implementation in this library:
