Jordan Kuehn

2 minutes ago, crossrulz said:

NI Week keynote.  Pure marketing BS.  Exactly what I expected from it.

Perfect. I know exactly what I missed. Thanks!

At risk of derailing my own topic I'd like to see if someone might be able to shed some light on my original problem. Below is a snippet of code that I've put together in an attempt to replicate a python routine that is not functioning properly. It works fine in python. Address is 1 and I have tried a variety of CS pins, modes, bit order, and asserting the Frame line or not.

And the Python routine attached, relevant sections below. This is for a RELAYPlate hat.

GPIO.setmode(GPIO.BCM)
RELAYbaseADDR=24
ppFRAME = 25
ppINT = 22
GPIO.setup(ppFRAME,GPIO.OUT)
GPIO.output(ppFRAME,False)  #Initialize FRAME signal
time.sleep(.001)            #let Pi-Plate reset SPI engine if necessary
GPIO.setup(ppINT, GPIO.IN, pull_up_down=GPIO.PUD_UP)
spi = spidev.SpiDev()
spi.open(0,1)	
localPath=site.getsitepackages()[0]
helpPath=localPath+'/piplates/RELAYhelp.txt'
#helpPath='RELAYhelp.txt'       #for development only
RPversion=1.1
# Version 1.0   -   initial release
# Version 1.1 - adjusted timing on command functions to compensate for RPi SPI changes

def getID(addr):
    global RELAYbaseADDR
    VerifyADDR(addr)   
    addr=addr+RELAYbaseADDR
    id=""
    arg = list(range(4))
    resp = []
    arg[0]=addr;
    arg[1]=0x1;
    arg[2]=0;
    arg[3]=0;
    ppFRAME = 25
    GPIO.output(ppFRAME,True)
    null=spi.xfer(arg,300000,60)
    #null = spi.writebytes(arg)
    count=0
#    time.sleep(.01)
    while (count<20): 
        dummy=spi.xfer([00],500000,20)
        if (dummy[0] != 0):
            num = dummy[0]
            id = id + chr(num)
            count = count + 1
        else:
            count=20
    GPIO.output(ppFRAME,False)
    return id

RELAYplate.py

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?

Quote

 

//Default To Mode 0 With No CS (LINX Uses GPIO When Performing Write)
		unsigned long spi_Mode = SPI_MODE_0;			
		if(ioctl(SpiHandles[channel], SPI_IOC_WR_MODE, &spi_Mode) < 0)	

 

On 1/12/2015 at 10:23 PM, ShaunR said:

Transport.lvlib, which this package depends on, has been updated. It uses a new installer which this one will also use so I will leave it a couple of days for people to check out and break it - then update Dispatcher.

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 😀

13 minutes ago, Darren said:

What versions of LabVIEW and the LINX Toolkit are you using/installing?

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):

Quote

Connecting to target...
Successfully connected to target.
Successfully connected to the target.
Target configuration updated.
OS Version: 10.3
CPU: BCM2835
Systemd Version: 
Has Internet Access: True
Device Type: Raspberry Pi 2 B

Connecting to target...
Successfully connected to target.
Successfully connected to the target.
Target configuration updated.
OS Version: 10.3
CPU: BCM2835
Systemd Version: 
Has Internet Access: True
Device Type: Raspberry Pi 2 B

blacklist spi-bcm2708is not present.dtparam=spi=on already exists.i2c-dev already exists.i2c-bcm2708 
blacklist i2c-bcm2708is not present.dtparam=i2c1=on
dtparam=i2c_arm=on already exists.
Adding MakerHub feed...
MakerHub Feed Already Exists
Updating package index.  This may take over 30 seconds depending on your internet speed...
Ign:1 http://feeds.labviewmakerhub.com/debian binary/ InRelease
Err:2 http://feeds.labviewmakerhub.com/debian binary/ Release
  404  Not Found [IP: 54.86.245.246 80]
Hit:3 http://archive.raspberrypi.org/debian buster InRelease
Hit:4 http://raspbian.raspberrypi.org/raspbian buster InRelease
Reading package lists...
Installing LabVIEW...
Reading package lists...
Building dependency tree...
Reading state information...
Rebooting Target...
Successfully connected to target.
Checking target status...

Installation failed.  If this is the first time the installation has failed try again.  If this error persists search, then post on the LabVIEW MakerHub forumsat labviewmakerhub.com/forums/linx.
Target configuration updated.
OS Version: 10.3
CPU: BCM2835
Systemd Version: 
Has Internet Access: True
Device Type: Raspberry Pi 2 B
 

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

Quote

9-10 PDT, 11-12noon CDT, 5-6pm BST, 6-7pm CEST

Raspberry Pi / LABVIEW CE and Sensors Sam Sharp Sam will demonstrate/show how to get started programming the Raspberry Pi using the LabVIEW 2020 Community Edition with a live/practical demo. He'll then expand this to show off his open-source library of drivers for a range of off-the-shelf sensors/hats so you can connect your Raspberry Pi to the physical world. Webex Link:https://agilent.webex.com/agilent/j.php?MTID=e635e8189d10f33d8a3f9a8761ce00c24 sam@mediamongrels.com

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.

17 minutes ago, hooovahh said:

Unrelated - Nice mouse I have the same one.  Well I did until I left it at the office just before a stay-at-home order.

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.

8 minutes ago, Rolf Kalbermatter said:

The Pi is very easy to get. I have here a Beaglebone Black and a myRIO available. Also a RIOTboard and an older Atmel SAM7X embedded controller board, but they both are not supported by Linx. The MCC HAT needs to have some form of binary module interface in the form of a shared library to be accessible from C. Interfacing that interface with the LabVIEW Call Library Node definitely must be possible, it's just some busy work to do.

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/

37 minutes ago, Rolf Kalbermatter said:

Send one my way and I have a prelimenary library done in a few days. 😀

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. 

Quote

MCC offers support for C (Linux) and/or Python only. LabVIEW is not a supported programming option for the MCC HATs. Currently there is no LabVIEW development in process for the HATs.

The reply I got back from MCC.

21 minutes ago, Michael Aivaliotis said:

Well considering NI owns MCCDAQ... It could be a good thing or a bad thing.

I was unaware of that. Good to know!

6 minutes ago, Michael Aivaliotis said:

I'm investigating this hardware which might fit your requirement: https://www.mccdaq.com/DAQ-HAT.aspx

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!

1 minute ago, Aristos Queue said:

Note above where I quoted another NI engineer about the complexity of answering that question given the variations of Pis available. We (NI) does not own one of every possible Pi. We are able to give the tech specs of what is supported, but the model numbers are not so straightforward in their mapping. Therefore, the table will have to be crowd sourced over time.

If you're shocked that the community has not built it yet, well, LV2020 CE only dropped on Tuesday. 🙂

Fair enough 😀

5 hours ago, Neil Pate said:

Check out this excellent presentation that covers a lot of the bases.

https://www.studiobods.com/en/niweek2019-ts170/

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... 😆

2 hours ago, Michael Aivaliotis said:

Creating a LabVIEW compatibility table should be the first thing on there, actually.

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