Jump to content

bbean

Members
  • Posts

    251
  • Joined

  • Last visited

  • Days Won

    7

Posts posted by bbean

  1. On 4/5/2022 at 8:56 AM, Phillip Brooks said:

    I am writing a wrapper to a Python class.

    The class has several states and will raise an exception when a method is called that is incompatible with the current state.

    Are there any best practices for passing exceptions back to LabVIEW? I was thinking of using the LabVIEW error cluster as a return type.

    That seems reasonable.  I have a wrapper class and pass back a pass/fail numeric and a status string,  but now thinking back it might have been more appropriate to just pass back a standard labview error cluster.

    In my case, the python wrapper can be run from either LabVIEW or directly in python.  The thing i struggle with is passing back real-time status that normally is provided in the terminal via python print statements when python scripts run stand-alone.  I'm testing an approach that just sends these via a UDP session but I haven't found a way to override the Python print command so that it prints to both the terminal (python scripts) and to the UDP session (LabVIEW VIs).

  2. 17 hours ago, Tlam said:

     But there is no plan "B", which is very unfortunate. I know what I want my automation software to do and look like, but it does not exist. I'm not sure I'm up to the task of making my own, so I guess I'm stuck with going to Python, unless NI suddenly changes course.

    What type of instrumentation and data acquisition systems does your lab work with ?  Mostly VISA type serial/gpib/LXI instruments or mostly data acquisition cards / PXI chassis type stuff?

  3. 1 hour ago, ShaunR said:

    If I buy a subscription license and then decide not to renew, what happens to my software?

    With subscription software, you will need to renew at the end of each term to maintain access to your software and associated services.  

     

    Yikes. Software as a service?

    This isn't enticing you to upgrade from LV 2009?😀

    • Haha 1
  4. On 4/23/2021 at 6:12 AM, pawhan11 said:

    Has anyone here successfully migrated from TestStand to some open source automation frameworks?

    In our hardware test we have a lot of things happening in parallel and so far I haven't found reliable alternative for TS. 

    I would investigate cosmos.  I haven't migrated a complete project to it yet but I'm implementing data collection, storage and telemetry GUIs to it for a new project working with python and FPGA programmers.  A lot of the python programmers use python and it as a replacement for LabVIEW/TestStand.  I haven't used their Script-Runner (TestStand-ish stuff) but the current version is highly capable for data collection, saving, presentation, limit checking.  They are working on cosmos 5 which will run in a docker container and have web based gui's

    • Like 1
  5. If you are using Win10 you can try the VI(s) in the attached LLB.  We typically create a "print" VI that shows all the controls, decorations logos etc we want to print, then run the VI in this llb.

    I threw the llb together real quick...hope everything works. 

     

    Win10PrintPDF.llb

  6. 1 hour ago, Thoric said:

    Their roles are:

    1. One is Dialogue style GUI Editor for populating an Array - a relatively simple actor.
    2. Another is a Dialogue style GUI Editor for a more complex file management need. Manages remotely (FTP) stored files.
    3. A third Dialogue style GUI Editor for managing another Array - a relatively simple actor, like (1).
    4. A local file management actor for receiving configurations and collating them into a JSON file - a simple decoupled actor with the ability to gather JSON objects from any other actor for storage and retrieval.
    5. A simple actor that adds log entries to a local text file, and uploads the local file to a remote FTP folder.

    So they don't all have one common dependency that the other actors don't also use. The first three present their FPs, but so do many other actors. Some depend on FTP interaction, using a separate internal library we have, but not exclusively so.

    I think I'll try cloning one of these 5 actors, trial build it then strip out 1 feature, and repeat until it builds successfully to determine which component is the problem...

    This is a long shot here, but do they all need to run in the UI thread but their preferred execution system is set to "same as caller" and then something gets screwed up when they are called by dynamic dispatch in the runtime?  What happens if you set their preferred execution system to "user interface" and retry.

     

  7. agreed.  As part of my trials and tribulations with MAX I had to repair NI VISA.  With NIPM18.5? no option to do that so they recommend uninstalling and reinstalling...fair enough.  Tried that and NIPM wanted to uninstall LabVIEW..wtf.   Upgrading to the latest version of NIPM (19.6) provided a better experience allowing you to repair installs now.

  8. Has anyone used IPFS as a tool for storing and distributing test data (multiple gigabytes)?  My use case would be to run tests that store data on local windows machines and then distribute that to other users who may have linux, windows etc and also to a centralized archiving location.  The users and test machines are in a relatively strict network environment and most users machines are locked down.  Some of the linux users may have elevated privileges to install things like ipfs but I'm worried about a typical windows user who may want to get the files easily without having to go through a bunch of command line steps to install ipfs on there machine after requesting elevated privileges.

     

  9. 9 hours ago, hooovahh said:

    I don't have anything to add other than I've seen this but not in any recent projects I've worked on.  It always frustrated me when I'd drill into some VI that was taking forever and it would be some property node or Read/Write/Open that was supposed to have a small timeout.

    Thanks for the quick response.  its a rather annoying problem.

    7 hours ago, Rolf Kalbermatter said:

    Once VISA calls into the Windows USB driver it can only hope that this driver will return within a reasonable time. I

    7 hours ago, Rolf Kalbermatter said:

    Personally I guess some previous command you send hasn't been fully processed by the device, or you haven't read the entire response, or haven't reset a status flag in the device or something like that. These things all shouldn't be able to lock up the USB interface, but they can and sometimes do.

    I think this may have been the problem but wont know until I test again on Monday.  You are correct that its a PM320E.  And so far their driver has been a pain.  The suspect command is the error query the parent class implements by default "SYST:ERR?" but PM320E requires ":SYST:ERR?".  A nuance (nuisance) that I failed to notice.

    PS.  I think I may have borked the instrument up by upgrading the firmware too.  Oh well thats what you get for trying to get something done before a holiday weekend.

  10. I have an issue where reading the VISA Instr Property "Intf Type" of a USB Instrument hangs for about 40 secs:

    image.png.9ef44f592496f4f476e4283bf033758c.png

    followed by an asynchronous VISA Write hang for 2+ minutes!  The timeout on the VISA instr session is set to 1000ms.   Here are the other details of the session:

    image.png.0c236366c08bfbd8820d54a1e25b6be2.png

    and here's a snip of the VI:

    image.png.f9de46c68c64e8f869afdc453baee7a1.png

     

    Any idea why these long timeouts are occurring?    or why the 1000ms timeout is being violated for both the Instr property call (no idea what goes on under the hood here) or the VISA write. 

     

  11. 6 minutes ago, drjdpowell said:

    By default, subVI are set to "Same as Caller" execution system, but they can be a specific system instead.  I suspect it might be just the subVI that does the TestStand call that needs to be in a different Execution System, not the calling Actor.vi itself.  So try just changing the subVI.

    If that doesn't work you may have to separate the TestStandAPI calls out.  Are you using your TestStand Actor as a GUI or user interface?  If so you may have to create another Actor to separate out the TestStand API calls that are causing the log jam into a new Actor....That new actor should not have any property/invoke nodes which would force its VI into the UI thread.

    • Thanks 1
  12. I worked on some Ethercat issue a few years back and remember that at the time the cRIO doesn't support Beckhoff array datatypes and we had to make individual IO variables for each item in the array on the Beckhoff side.  Were you able to import the XML file OK into the LabVIEW project?

  13. If you don't need to do FPGA image processing, I would explore the other options for Camera Link cards that are not FPGA based and see if they will work with Pharlap

    With regards to the FPGA example, this may be a long shot If you haven't compiled FPGA code and I'm not sure it will work at all.  I don't have time right now to fully explain but to summarize:

    • Open the example 1477 getting started project
    • Save a copy of the project and all VIs to a new location (so you don't overwrite the working windows target version from NI)
    • Close the off the shelf example project
    • Open the copy project
    • Create a new RT target in the project (right click on project in project tree, select new targets and devices, select RT desktop
    • Move the FPGA Target from the Windows Target to the RT Desktop target
    • Move the Host VI from the windows target to the RT target
    • Compile the FPGA target VI
    • Open the Host VI  (now in the realtime target) and reconfigure the Open FGPA reference to point to the new compiled FPGA VI.
  14.  

    What do you think of this solution?

    I guess I would need to know about your requirements, but I think that would be a road less traveled.  Do you need base, medium, full or extended full? do you need power over camera link? etc.   Why do you need real-time?

    In the future I would recommend talking with Robert Eastland and purchasing all your vision related hardware /software from Graftek.  He has been extremely helpful with me in the past and knows his stuff.  I have no affiliation with the company.

    Did you try my suggestion to compile the example FPGA code and move the host example to the real-time target to see if its even a possibility?

     

  15.  

    According to the specification:

    http://download.ni.com/support/softlib//vision/Vision Acquisition Software/18.5/readme_VAS.html

    NI-IMAQ I/O is driver software for controlling reconfigurable input/output (RIO) on image acquisition devices and real-time targets. The following hardware is supported by NI-IMAQ I/O:

    .......

    • NI PCIe-1473R
    • NI PCIe-1473R-LX110
    • NI PCIe-1477

     

    the frame grabbers should work under Labview Realtime. Do you see it that way?


    The statement of NI (Munich) is now (after the purchase) that the frame grabber PCIe 1477 should not work under Labview Realtime.

    I also had the impression that NI was not really interested in solving the problem. For those, Labview Realtime is an obsolete product.

    The question to NI (Munich) whether the frame grabber PCIe 1473r works under Labview Realtime has not been answered until today.

    Too bad that nobody else made experience with the frame grabbers under Labview Realtime.

    A nice week start

    Jim

    Unfortunately, the card probably does not work directly in LabVIEW Realtime.  NI's specifications and documentation are often vague with hidden gotchas.  I had a similar problem with an NI-serial card years ago when Real-time and FPGA first debuted.   I wanted to use the serial card directly in LabVIEW real-time with VISA, but I ended up having to code a serial FPGA program on the card because VISA did not recognize it as a serial port early on.

    Is there anyway you can try to compile the FPGA example and download it to the card?

    C:\Program Files (x86)\National Instruments\LabVIEW 2018\examples\Vision-RIO\PCIe-1477\PCIe-1477 Getting Started\PCIe-1477 Getting Started.lvproj

    After you compile and download the FPGA code to the 1477, I think you would have to move "PCIe-1477 Getting Started\Getting Started (Host).vi" from windows target to the Real-time target, open it up and see if it can be run.

     

  16.  

    The FPGA tool is also available. The frame grabber runs on the same PC under Windows 7 (other hard disk).
    Does anyone have an idea why the frame grabber is not recognized in realtime?

    a nice weekend

    Jim

    At least for the 1473R according to this:

    https://forums.ni.com/t5/Instrument-Control-GPIB-Serial/My-Basler-acA2040-180km-NIR-is-not-visible-in-NI-MAX/m-p/2402066/highlight/true#M59080

    "The NI PCIe-1473R Frame Grabber contains a reconfigurable FPGA in the image path enabling on-board image processing. This means that the full communication between the camera and the frame grabber goes through the FPGA. It is then a major difference comparing to the other standard frame grabber without FPGA. 

    "It means also that the camera will not shows up in Measurement & Automation Explorer."

    I'm guessing here but I think you have to create a new Flex RIO FPGA project with option for the card

    https://forums.ni.com/t5/Machine-Vision/PCIe-1473R-fpga-project/td-p/2123826

    Maybe look and see if you can compile an example from here

    https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000kIBdSAM&l=en-US

    ..\Program Files (x86)\National Instruments\LabVIEW 2018\examples\Vision-RIO\

     

×
×
  • Create New...

Important Information

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