Jump to content

Jordan Kuehn

Members
  • Content Count

    552
  • Joined

  • Last visited

  • Days Won

    12

Posts posted by Jordan Kuehn

  1. I just found this thread and have been getting hit by this pretty hard on my current project. That and classes locking when I have a typedef used on two targets. LV 2020. Is the answer really just to break my projects apart into Windows and RT? I've not had to do this in the past, but I haven't had as extensive use of classes on the RT side before.

  2. 18 hours ago, Renny Sadala said:

    Previously, i loaded the folder containing my all classes (for example the folder Host_Class). I had placed this folder in the path /home/lvuser/natinst/bin/. I.e I will had  /home/lvuser/natinst/bin/Host_Class

    Now, i place directly my classes in the path /home/lvuser/natinst/bin/  and not via a directory like Host_Class.

    Apparently, By default, when RT target runs, the reading is limited only to the path specified in the RT target properties. In my case, this path is /home/lvuser/natinst/bin/

     
     

     

    You might check the folder permissions for the folder you created. I have ran into issues with that before. 

  3. 18 hours ago, Neil Pate said:

    Another weird thing. When I close a project it often does not close the open VIs that are part of the project!

    Maybe my installation is just busticated.

    I get that one some projects and not others. I'm used to being able to close out the project and it closing everything else out and prompting to save. But I don't think that's only on 2020, I have it in 2018 as well, same projects.

  4. 2 hours ago, Neil Pate said:

    Absolutely. This is such a good tool it is a bit sad NI does not officially endorse this.

    By the way I found this thread a bit more current

    https://forums.ni.com/t5/LabVIEW-Real-Time-Idea-Exchange/Provide-a-Virtual-Machine-VM-in-which-to-run-LV-RT-systems-on/idi-p/1069833#comments

    In particular this post with step-by-step instructions on how to begin: https://forums.ni.com/t5/LabVIEW-Real-Time-Idea-Exchange/Provide-a-Virtual-Machine-VM-in-which-to-run-LV-RT-systems-on/idc-p/3953070/highlight/true#M598

    with a bit of further info instruction here to get the embedded GUI up and running: https://forums.ni.com/t5/LabVIEW-Real-Time-Idea-Exchange/Provide-a-Virtual-Machine-VM-in-which-to-run-LV-RT-systems-on/idc-p/3953394/highlight/true#M603

    Thanks for all the links. I had seen discussion some time back and had never jumped through the hoops to make it happen. Currently I have three different cRIOs on my desk which gets to be expensive. I'll give this a shot!

  5. 1 hour ago, Neil Pate said:

    My latest weird project bug with LV2020 is when I close the project it does not automatically close any windows I had open 🤬

    I was getting this in LV2018. I get something similar still in LV2020, as well as projects that don't seem to leave memory even after they are all closed out to the main LV screen. They open back up instantly.

  6. On 6/16/2020 at 12:33 PM, Rolf Kalbermatter said:

    Well, one problem is that your Python script uses GPIO pin numbers while Linx uses connector pin numbers. Now the GPIO25 happens to be Linx pin 22, so you got that right. But the GPIO22 pin is the Linx pin 15 and you configure that as custom CS signal. This is wrong.

    The Python script sets this explicitly to be an input and with pullup resistor. The Linx custom CS handling will set this as output and actively drive it, asserting it before every frame and deasserting it afterwards. This is likely going to conflict with whatever your hat is trying to do.

    There are two things you can try:

    - Set the custom CS pin for the SPI ReadWrite function to a pin number that is not connected to any pin on your hardware. That will make sure it doesn't conflict with your hardware. Call before the Digital Write for pin 22 an explicit Digital Read for pin 15. This will make sure the digital pin is configured as input. Unfortunately Linx does not allow you currently to configure a pullup/pulldown pinstate, but it may be enough to let your hardware work.

    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.

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

    587658617_TestRelayPlateSnippet.png.d476d1ce70b822d7531c320f1e2ac71e.png

     

    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

  8. 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?

  9. 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)	

     

     

  10. 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!

  11. 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?

     

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

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

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

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

     

×
×
  • Create New...

Important Information

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