Leaderboard

I have published a 0.3.1 package on VIPM.io with Antoine's changes (LabVIEW 2017). Then I've accepted your Pull Requests and published a 0.4.0 version as well (LabVIEW 2019): https://www.vipm.io/package/jdp_science_postgresql/

该文件中有四行头文件 (4 rows of header in this file) 下面是一个程序，它将读取四个标题行，然后每次读取其余的 100 行 read csv per chunk of 100 rows.vi

Writing strings to TDMS that are a byte stream can be tricky. I have a Read/Write Cluster to TDMS and it flattens it to a string. But as you noticed there needs to be special consideration for null. Well it also turns out that on different platforms there are other characters that need special attention too. You can absolutely do extra work on your images. But I fear that you won't get the performance you want. TDMS is crazy fast and all, but it sounds like a bonkers amount of data real fast, and I don't know if it will be able to keep up, especially if there is special code needed to convert a string ready to be written to TDMS so the null (and any other characters you want) get written correctly. Writing an array of bytes also sounds crazy for this application. The number of samples on the channels might approach NI's limitations for the data type, and then keeping track of where the offsets are for files would need to be a separate channel. I've done stuff like this for logging raw CAN frames to TDMS files but that seems like way less data. Honestly you might be better served writing to binary files, then having the TDMS file just keep an index of the file names or locations for replay. Not sure how I'd go about solving this.

It's not listed in https://www.ni.com/en/support/documentation/bugs/24/labview-2024-q3-bug-fixes.html As LabVIEW user I feel happy for their attention to this. As OpenG ZIP developer I feel a bit cheated. 😁

Guess who's back? Back again? Spammers back. Tell Admin...

When you search for a LabVIEW toolkit, you should start on www.vipm.io Take a look at this one : https://www.vipm.io/package/hse_lib_gitlab_api/ if you need support HSE has a discord server, they are quite responsive.

What have you tried so far? https://docs.gitlab.com/ee/api/rest/ documents a REST API to gitlab servers. Did you look at that? Did you try anything? There is for instance the JKI REST API Toolkit that should let you talk to this.

My derived clock only goes as low as 4.69 MHz. My device is CRIO-9043

I fully agree that anything, even smoke signals in the wind, are better that NSVs. I'm using Redis, I also started from an existing lib found on the interweb, tweaked a bit for my needs. We now have multiple golang services as well as LabVIEW services connecting to Redis for cache and using RabbitMq for messaging. For some small tests on my Windows machine I've used Redis on WSL, easy to use. At the next local user group meeting I might do a short presentation about it, if you have faced any issues, I'd be interested in your feedback. Cheers

Coming back to report. Scavenging the net I've found essentially three set of connectors between Redis and LV: what can be downloaded from https://forums.ni.com/t5/Example-Code/REDIS-database-LabVIEW-toolkit/tac-p/3508611 taking into account the corrections listed in the thread. This seems to be the more widespread, considering even that it was shown as an option at the CERN LV user group this year (see https://indico.cern.ch/event/1388470/contributions/5911487/attachments/2843544/4971934/lugm_LabVIEW_at_CERN.pdf, slide 22). Dates originally to 2014. Nick Folse's https://github.com/tauterra/Redis-Client-for-LabVIEW of about three years ago, according to its author no further developed. Found a couple of flaws, easily corrected. https://github.com/Bas-vE/LV-Redis , which claims to be an evolution of 1., promoted to LVOOP. Most recent of the three. The philosophy of the three toolboxes differs somewhat from one to the other, the first one being more of the kind "one VI for each Redis command", the others putting perhaps more the accent on the transaction protocol than on the completeness of the commands implemented. Redis's huge command set also expanded during the years in question. However, I found in all three something which looks to me a bit of a no brainer, which is that TCP client connection are opened and then closed for each elementary operation. While that might have a minor performance impact, I found that the approach prevents Redis' MULTI pipelining. I have forked 1. in https://github.com/EastEriq/redis-in-labview and 2. in https://github.com/EastEriq/Redis-Client-for-LabVIEW for dwelving into. Finally, I have resolved for adopting my fork and augmentation of 1. in my project, but only after I modified it so that TCP connections can be kept open throughout the client sessions.

@hooovahh Is still weeding out the spam. I think he's in the eastern US time zone so he's 3 hrs. ahead of me ☺️. Much thanks to him. But I'm also improving the filters. Unfortunately, I think there are some sleeper accounts that were created before the changes that are starting to post. But, yes, I think it's getting much better. BTW, I just discovered that if you ctrl+right click a posted image you can set its' size! neat.

Says the account with "AI" right in the name. Hiding in plain sight! eta: In fact, you can't even pronounce it without saying "AI" - "A I va lee oh tis". Well, I can't, anyway...