Jump to content

Jordan Kuehn

Members
  • Content Count

    544
  • Joined

  • Last visited

  • Days Won

    12

Jordan Kuehn last won the day on February 26 2016

Jordan Kuehn had the most liked content!

Community Reputation

75

1 Follower

About Jordan Kuehn

Profile Information

  • Gender
    Male
  • Location
    Chicago

LabVIEW Information

  • Version
    LabVIEW 2018
  • Since
    2009

Contact Methods

Recent Profile Visitors

2,570 profile views
  1. It seems to me that it sometimes wants to open the VIPM Browser instead or if one is open the other one doesn't want to open. I need to retrace my steps to recreate the issue, but I noticed some strange behavior in the past, also in a VM. A restart got things working again too.
  2. Thank you for the pointers. Unfortunately that didn't work either. Does the ioctrl c command behave differently than spidev in python? I may be able to give this a shot again in some time, but for now I was able to use a combination of the SSH trick and calling python commands from the CLI to get things working, albeit slowly. Figured I would at least leave a note here for now.
  3. 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
  4. 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.
  5. 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?
  6. 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?
  7. Did this update happen and is this alive still? Looking to give it a try on some linux targets as well as Windows. Thanks!
  8. The QwaveSys Raspberry Pi Package for LabVIEW 2.0 appears to install the Digilent LINX Toolkit as a dependency.
  9. 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?
  10. 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 😀
  11. Good question. This is LV2020 Community Edition in a VM. The toolkit VIPM pulled down is Digilent LINX version 3.0.1.192.
  12. 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.
  13. 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
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.