Jordan Kuehn

If they would make the product page usable again I wouldn't care one bit. It is absolutely miserable to find a c-series module for example. They did at least move the data sheet link to the pop-up but wow is that thing bloated and terrible.

I also noticed after looking around some more that it was a static call to spidev0.1. Ironically this is what I think I need so I may have another issue. It sounds like you are making some serious updates to the code. I agree that if there is no arbitrary CS pin selected it shouldn't force you to pick one and toggle it for no reason. Are you planning to submit these changes as part of a contribution to the github or release the changes at all?

After some googling and looking at the LINX Source Code I could find, it seems like the SPI functions do not make use of the CE lines on the Raspberry Pi and perhaps default to CE0 in parallel with whatever GPIO line is selected by the user. The device I'm looking to connect to uses CE1 and I'm having some trouble finding a way to make this work, short of breadboarding the thing and making the connections manually. Does anyone have any insight here?

Did this update happen and is this alive still? Looking to give it a try on some linux targets as well as Windows. Thanks!

The QwaveSys Raspberry Pi Package for LabVIEW 2.0 appears to install the Digilent LINX Toolkit as a dependency.

I have an application where I have a handful of windows and linux cRIOs (and potentially RPis) that all need to talk to each other and (already) communicate to an existing remote MQTT AWS instance. Some of the discussion at the end of this topic is relevant as I've looked at DDS, but I didn't want to resurrect that post and take it further off topic. The licensing for DDS is quite expensive and they don't have a "LabVIEW toolkit" pricing package, rather a mix of product line pricing per project and developer licenses. The speed and "determinism" of the databus is attractive, but perhaps unnecessary for this application. The built in LabVIEW options aren't as flexible as I would like in regard to automatic discovery and establishing connections (and NSVs are not supported on RPi, but streams might be?), but I would be happy to have my mind changed. This all is to say I keep coming back to the concept of using MQTT locally as well as remotely and bridge the brokers, much of the logic is in place or could expand to fit the local requirements. The local communication would handle commands and tags/current values between systems and the brokers would package a subset of that to be sent remotely. This blog post from 2017 gave me some inspiration. Has anyone gone down this road and has any feedback or suggestions pro/con?

I had originally left things as is. However, there was an error with the LMH-LINX I2C Open VI when I tried to run it in an example program. It was an unknown error. That is what prompted me to pull down the LINX toolkit from VIPM thinking there was a more up to date version. This did resolve the error and things worked after that. Until I tried to configure another Pi. Is the LMH-LINX toolkit also included with LV2020CE? I supposed it's possible that I had that dependency included in the example code I was running (The Automation Hat code from MediaMongrels that I grabbed from the VIWeek presentation) and it was somehow out of date. If this is of interest I can recreate this as it's just in a VM. I don't like that installing the package broke the tool included in CE, but I will not make that mistake again 😀

Good question. This is LV2020 Community Edition in a VM. The toolkit VIPM pulled down is Digilent LINX version 3.0.1.192.

So, I decided to try formatting the SD card once more and running the repaired LINX installer. That seems to have solved my problem. However, I am a little disturbed that installing the LINX package broke the built-in LINX tools and seemingly reverted them to the LV 2014 version. I don't think I did anything out of the box here, just opened the VI Package Browser and installed the LINX toolkit.

I am working with a Raspberry Pi 3b and am having trouble with running the LINX Target Configuration on it. I had initially done this without issue. Then I reformatted the SD card and tried to do this on a Raspberry Pi 4 and the installation failed. I formatted the card again and tried to go back to the 3b and cannot get it to work. I had installed the LINX package from VIPM when working with it initially and that seemed to fix some connection issues in the labview code, but it also changed the target configuration wizard. I've uninstalled the toolkit, repaired the LV installation and it is back to the original wizard, but still it is giving me an issue. Now I finally have an error log to look at and there seems to be an issue with the feed from Labviewmakerhub as shown below (also it thinks it's a Pi 2 b for some reason, but it did that the first time too): Any suggestions on what to try next? LINX_Log.txt

We had a customer a while back use GSM modems from SEA like this and configure it with a VPN that worked well for them. I believe when all was said and done it could be targeted from within the Project Explorer on the local PC in LabVIEW even, in addition to accessing it via FTP/MAX/etc. I can look back through my notes and see if anything else jumps out, but I think this is a good approach if you can deal with setting the VPN up.

From the VIWeeks post: Tuesday 19th May

To be fair, CG has so many oddities regarding where you need to place the mouse to get Auto-tool to work correctly as well. For most of us they are second nature, but at times when I'm coding in front of someone I suddenly realize how ridiculous (and intricate) some of the mouse work is. I also notice when having to code over a remote connection and there is even a tiny lag on the mouse.

I've had this one for years now and I love it. Fortunately (or unfortunately) the stay-at-home order has not affected my daily commute to the home office.

You always make me smile when I read something similar to "just some busy work to do"! It's been a long time since I have had occasion to make LabVIEW wrappers with the CLFN and I did not relish that experience! Perhaps the open source code is workable? https://github.com/mccdaq/daqhats/

A raspberry pi or an MCC HAT? I’d send you a pi, but I doubt I’ll buy a HAT until I know it will work with LabVIEW.

The reply I got back from MCC.

I was unaware of that. Good to know!

I too was looking at those hats. I haven't gotten too deep into it, but it does seem like they haven't built LV drivers for them yet and would require calling some custom commands from the Raspberry Pi. At least according to the existing LINX webpage: https://www.labviewmakerhub.com/doku.php?id=libraries:linx:faq#6 However, I have used MCCDAQ products before (TC-32) and they do seem to have some good LV support in house. I wouldn't be surprised if they add support to the product. If I'm wrong about needing custom commands/drivers that would be great!

Fair enough 😀

Perfect, thank you! I think I was at this presentation, but I lost the information.

I've seen the demos for webuis at NI Weeks past and it is an intriguing part of NXG for me, but not enough to get me to move over. Well, that and nearly every project I work on involves RT... But with the community edition I may wade in a little. Anyone care to point me in the right direction? I suppose I could just install it and see what gets thrown at me in terms of shipping examples... 😆

I'm shocked that one isn't already available.

Awesome. Thanks!

Does that mean the toolkit is compatible with any ARM V7 Pi? A simple compatibility list/chart would be helpful. I'm looking at the Pi Compute 3+ for example as well as Pi 3 and 4.