Jump to content

Ryan Vallieu

Members
  • Content Count

    9
  • Joined

  • Last visited

Community Reputation

0

About Ryan Vallieu

  • Rank
    LAVA groupie

LabVIEW Information

  • Version
    LabVIEW 2018
  • Since
    2003

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Rearranging the cases in the Type Specification Structure so that the default LabVIEW function is the LAST case restores expected behavior (I think)...not sure if this is what was intended...
  2. Broken Class adaptation in Malleable VIs in 2019: There is a difference in the code that I missed before. See the attached file with the screen shots. In LabVIEW 2018 Example Code the top level Search Unsorted 1D Array.vim has in TSS Case 1 the normal Search 1D Array function, but the start index and element are UNWIRED - thus this case would be broken. In LabVIEW 2019 Example Code the top level Search Unsorted 1D Array.vim has in TSS case 1 the normal Search 1D Array function, but the start index and element are WIRED - thus this case is not broken. The Assert Structural Type Match function is only configured to look at the Functor input - and thus with it unwired this case is selected. Malleable Nested VIM - Lesson 2B Convert to Instances.pdf
  3. Follow-up, the Serial cards are now working, had to make sure the driver was properly installed. Then we found an issue with the online instructions for the serial loopback test and the recommended cable to connect the RJ50 to a DB9 breakout for feedback loop wiring. The incorrect cable was called out on the instructions. The 192190-01 is not the correct cable. The 182845-01 is the correct cable that matches the usual serial pinouts. You can use a 192190-01 but you need the pinouts to determine the correct pins.
  4. I have seemingly found an issue with the shipping example code for Nested Malleable VIs. Another user has verified that he saw the same behavior in 2019. I am working through the examples and the presentation from NIWeek 2019. In running the Lesson 2b code (C:\Program Files (x86)\National Instruments\LabVIEW 2019\examples\Malleable VIs\Nested Malleable VIs) I found the Equals.vi in the class was not being leveraged and the search failed. When I went to my LabVIEW 2018 machine and ran the Lesson 2b.vi the code worked to find the element by correctly leveraging the in-class Equals.vi. One difference I see is that in the 2018 example the Equal.vi is in the example folder with the code, and in 2019 the Equal.vi has been moved to VI.lib - otherwise the code looks to be the same. The Equals.vi code looks identical, and the calling VIM look identical. I posted on the LabVIEW NI.com forum here: https://forums.ni.com/t5/LabVIEW/LabVIEW-2019-Malleable-VIs-Shipping-Examples-Lesson-2b-Nested/m-p/3966044/highlight/false#M1129678 I am trying to determine what may have broken or changed between the implementation in 2018 and 2019, visually the code looks the same.
  5. I've got an actual PXIe-8135 running CentOS 7.6 with LV 2018, VISA, DAQmx installed. I did get DAQmx working successfully - the serial cards in my chassis are what are throwing me for a loop. LabVIEW Wire Mode property is not supported in CentOS/RHEL for some reason and despite the README stating that the card should default to the 4-wire mode, when I check it is reading as RS232_DTE, and does not pass a loopback test.
  6. I created a separate VI with the Scripting node and got the same Error 42 when modifying the INstanceInfo. I believe it was because there was just something wrong with the original PolyVI - I recreated it programmatically with scripting code, then used the tool, and now I am not getting an error on modify/save in the tool. Something must have been corrupt.
  7. Even more strange. Started a new Poly VI from scratch in Documents folder. No VIs added to it, just created New in LV 2016 and saved. Opened tool, added two VIs to the list, click Save VI - get Error 43, operation cancelled by user!? I didn't cancel any dialog.
  8. I should have thought to check that, but since the LabVIEW Editor was saving it fine it didn't occur to me. I will check. EDIT: It won't even let me save a new copy in the Documents folder - same error. Windows 7 evidently doesn't let Administrators remove Read Only from the Microsoft description - odd, even using the cmd prompt to attrib -r c:/<folder> on the folder and trying again to save yielded error 42. I will try a separate version of the Polymorphic Scripting node in some test code in LabVIEW to see if I can replicate the issue.
  9. Hmm. When trying this out an doing a save after an Edit - I am given Error 42. Error 42 Occured at Property Node (arg 1) in Polymorphic Editor.lvlib:Apply Changes.vi->Polymorphic Editor.lvlib:PolymorphicGUIEditor.vi
×
×
  • Create New...

Important Information

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