Jump to content

Search the Community

Showing results for tags 'python node'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Software & Hardware Discussions
    • LabVIEW Community Edition
    • LabVIEW General
    • LabVIEW (By Category)
    • Hardware
  • Resources
    • LabVIEW Getting Started
    • GCentral
    • Code Repository (Certified)
    • LAVA Code on LabVIEW Tools Network
    • Code In-Development
    • OpenG
  • Community
    • LAVA Lounge
    • LabVIEW Feedback for NI
    • LabVIEW Ecosystem
  • LAVA Site Related
    • Site Feedback & Support
    • Wiki Help


  • *Uncertified*
  • LabVIEW Tools Network Certified
    • VI Scripting
    • JKI Right-Click Framework Plugins
    • Quick Drop Plugins
    • XNodes
  • General
  • User Interface
    • X-Controls
    • Custom Probes
  • Database & File IO
  • Machine Vision & Imaging
  • Remote Control, Monitoring and the Internet
  • Hardware

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start



Personal Website

Company Website

Twitter Name

LinkedIn Profile

Facebook Page



Found 2 results

  1. Take an Open Python Session Node, pass an error cluster with a non-zero error code (but otherwise status = FALSE and empty Source string), connect the outputs to a Python Node (and use a Close Python Session node if you want afterwards). Run. The Open Session Node transmits the warning (so doesn't generate an error) but the following Python Node converts the warning into an error (same code, TRUE status and source = Python Node in Calling VI name). That is unexpected.
  2. The snippet below shows some oddity I uncovered while trying to document a bit of code involving the Python node. The error constant is just here to provide a cluster input to the node (which is what the "Marshal to Named Tuples" is supposed to handle). The Always Copy node is here to go around the known problem that the comment arrow will snap to the middle of the wire it is attached to, NOT where the user connects it to the wire (and that of course will never change). The comments indicate that the first node input (which happens to be the return argument, but that has no bearing o the observed behavior) has been right-clicked and "Marshal to Named Tuples" was used. By contrast, the second node input has had no modification applied. The result (surprising to me) of the "Marshal to Named Tuples" option was that the wire broke, as if the node lost its ability to "read" the cluster element names. Obviously no such thing happens when making a copy of anything (you can still hover over the lower branch of the wire with a probe and the Help window will show all 3 cluster element names). I am erring on the side of calling this a bug, but it might just be some kind of arcane feature of the node which only its author is familiar with (and I don't really whether or not it changes in the future since I am dug in 2021 SP1). But here it is for every one to gawk at.
  • Create New...

Important Information

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