Jump to content

Ryan Vallieu

  • Posts

  • Joined

  • Last visited

Everything posted by Ryan Vallieu

  1. Using the valueLabel and then either TypeCast or GetValueByPointer.xnode to convert from string is working. Thanks for the insight and the gained knowledge.
  2. Well I have the basic union code isolated and the LabVIEW wrapper seems to work to call into the function. Thanks guys!
  3. That info about Long on Linux being 64-bit cleared up a bunch of issues around the other function calls provided to me. The old system being interfaced is a Solaris system returning 32-bit Long information and the sendLong function called out on the PXIe CentOS system was sending out 64-bit Long types to the Solaris system, so all the messages had 32 extra bits of information. I've made the owner of the API aware of the issue that Long is not guaranteed to be 32-bit on a system so the API must be reworked.
  4. Thanks Rolf! I am on CentOS 7.6 64-bit on a PXIe-8135. Got side tracked, gonna make a test code that feeds constants through that data structure and wrap that so I can know what to expect for data. Thanks, giving that a go this morning.
  5. valueLabel is a typedef enum typedef enum { noValue = 0, InstrumentServiceName, NetworkPortNumber, ComponentID, ScanRate, Slot, NumChannels, ChannelNumber, CardNumber, FirstChannelNum, IEEE488_Address, VXI_Address, SerialNumber, SensorID, ScanListItem, Gain, Filter, Excitation, Cluster, Rack, PCUtype, EUtype, RefType, PCUpressure, MaxPressure, AcqMode, CalTolerance, CalPressure1, CalPressure2, CalPressure3, CalPressure4, CalPressure5, DataFormat, ThermoSensorType, ThermoSensorSubType, SensorType, MaxValue, SwitchState, OrderForAction, RcalFlag, CalDelayTime, CalShuttleDelayTime, nfr, frd, msd, MeasSetsPerSec, ServerName, RefPCUCRS, CalMode, ZeroEnable, NullEnable, ZeroMode, RezeroDelay, SensorSubType, ModuleType, ModuleMode, MeasSetsPerTempSet, CardType, Threshold, ControlInitState, ControlPolarity, StateEntryLogicType, StateEntryDelay, StateExitLogicType, StateExitDelay, TriggerType, TriggerEdge, ScansPerRDB, InterruptLevel, CSR_Address, Program_Address, ScannerRange, Hostname, ConnectVersion, From, To, ShuntValue, ValveConfig, NextToLastLabel, lastLabel, EndOfValList = 9999 } valueLabel; and valueType is also defined as an Enum typedef enum { noValueType = 0, integer = 1, floating = 2, charString = 3, uLong = 4, maxValueType, EndOfValTypeList = 9999 } valueType;
  6. I have code from another developer that allows me to interface with a server to get configuration data. I have compiled the C code into a .SO on my Linux system without error - but in writing my LabVIEW CLFN, I am unsure what to do with a Union Pointer to pass the data. The function in the C file: void getValue(int so, CharacteristicHandle ch, Value *v) { long longValue; unsigned long ulongValue; double doubleValue; char * c_ptr = 0; long msgType = g_val; sendLong( so, msgType ); sendCHARhandle( so, ch ); readLong( so, &longValue ); v->order = longValue; readLong( so, &longValue ); v->type = longValue; readLong( so, &longValue ); v->label = longValue; switch( v->type ) { case integer: { readLong( so, &longValue ); v->v.l = longValue; break; } case uLong: { readLong( so, &ulongValue ); v->v.ul = ulongValue; break; } case floating: { readDouble( so, &doubleValue ); v->v.d = doubleValue; break; } case charString: { readString( so, &c_ptr ); v->v.s = c_ptr; break; } } return; } The definition of "Value" from another header file: /* Define a type to hold the value and type information for * a characteristic. */ typedef struct Value { union /* This holds the value. */ { long l; unsigned long ul; double d; char *s; /* If a string user is responsible for * allocating memory. */ } v; long order; valueType type; /* Int,float, or string */ valueLabel label; /* Description of characteristic -- what is it? */ } Value; I'm a newb at CLFN - the primitive datatypes I've got working for my other calls - this one I am not sure how to configure with the CLFN. Is this possible to do with the CLFN?
  7. Solution: Since we need xinetd to be able to open N number of LabVIEW VIs as this is how the legacy system is configured and the "institution" doesn't want to change that at this point, I had to figure out how to make this work. Compiled my test VI into a .SO Shared Object library on my PXIe-8135 running Cent OS 7.6. Selected Advanced options in Build to use EMBEDDED version of run-time engine - doesn't require a GUI for the code to run. Wrote simple c code to launch the LabVIEW VI. Installed and configured xinetd to launch C code that launches LabVIEW code. Used the package: xinetd-2.3.15-14.el7.x86_64.rpm LabVIEW Test VI uses LabVIEW Linux Pipe VIs with hard coded 0 (STDIN) and 1 (STDOUT) to communicate over the socket. As explained basically here: http://www.troubleshooters.com/codecorn/sockets/ Result is that the LabVIEW code runs and can communicate over the Socket connection through the Pipe VIs. It turned out to be easier on the LabVIEW side than I expected. Hard coding the 0 and 1 into the Read from Pipe.vi and Write to Pipe.vi worked.
  8. This has since changed. I am now compiling my LabVIEW code into .SO library and calling that from C as apparently I can only get xinetd to launch one instance of LabVIEW, the system must be set to run-at start-up, etc. etc. I can call any number of LabVIEW VIs from .SO through a C call and have them happily chugging away in their own app spaces. What I am missing still is how to get the STDIN/STDOUT through to the LabVIEW program. I suspect if I was better at C this would be easy (easier?). Just trying out a simple demo at first so the LabVIEW code doesn't need to be a full-blown architecture. I just need to get that damn "pipe" or File Descriptor.
  9. I've got a need for ONC-RPC from LabVIEW running on a Linux system. Looks like that library link is dead that you posted. I will try to dig around to see if it just moved. Does anyone know of existing toolkits? I'd look at VIPM, but my main laptop died and is being fixed and I am not allowed to install any software on this loaner PC.
  10. I am trying to figure out how to get LabVIEW EXE running on NI Linux RT for PXI 2019 to communicate over System.in and System.out when it is called by xinetd so that the Client that connected can communicate to the LabVIEW exe. I don't have the Pipes VIs on the palette on the RT VI functions palette. Maybe LabVIEW RT doesn't realize it is running on Linux. Is there a simple way to accomplish this that I just don't know about from my limited Linux experience?
  11. I know this is an old topic, but I am trying to figure out how to get the Pipes VIs in LV 2019 for LabVIEW running on NI LabVIEW Linut RT for PXI. The pipes VIs are not on the Connectivity/Library in the RT palettes for the PXI Linux RT system. I wonder if it has to be Linux "Desktop" installation of LabVIEW for those VIs to show up on the palette and how we could get them on Linux RT for PXI? Hmm.
  12. Hmm the link to the NI page no longer works, that stinks.
  13. Anyone have an 8 GB memory chip in their PXIe-8840QC? If you do can you let me know the part number? I'm working on netboot and need to increase my RAM from the 4GB included. Yes, I know NI sells NI part number 783001-8192, but I am expecting a ridiculously high quote for something that should only cost $200 maximum in the worst case. I'm thinking Micron MT16KTF1G64HZ-1G9P1, Memory Module DDR3L SDRAM 8GB 1866MT/s 204-SODIMM would work, just rather know if someone has an 8GB memory that is known working. What's in it from NI is the 4GB Micron MT8KTF51264HZ-1G9P1 (PC3L-14900S-13-13-B4, 4 GB 1Rx8 ), Memory Module DDR3L SDRAM 4GB 1866MT/s 204-SODIMM
  14. Well I was playnig around with PXE boot and the PXIe controller and got the system to PXE boot with tftp and using the kernel bzImage and initramfs files from /boot/.safe - but that is only the safemode boot image. But it worked properly and demonstrated to me that if things are done correctly I should be able to PXE boot. Checking the LVRT repo on Github, I noted it mentioned building the kernel and installing in the folder location /boot/runmode <- in this folder I found the runmode kernel bzImage file and runmode initramfs Trying to use those files for the PXE boot, the kernel loads, but there is an error with the initramfs loading.
  15. I am attempting to configure (or attempting to learn to configure, which is step 1) our National Instruments PXIe-8840QC system that is running NI Linux RT for PXI 2019 (what is purportedly OpenEmbedded Linux with the Preempt-RT patch) to Netboot with a Linux Server. I have demonstrated netboot with the server using another target with CentOS. I'm having trouble trying to figure out how to capture or build the initramfs .img file that I need to reference on the Server for the PXI system. I have found a folder on the system labeled ./lib/modules/4.14.87-rt49-cg-7.0.0f0-x64-189-build/include/config/intramfs when I do a find for initramfs - but there is not an .img file in the /boot folder like I have been used to seeing. Anyone have any insight to impart on building the initramfs~.img file from my existing Linux system? We need to Netboot in order to run our systems diskless. We run secret level tests and SOP is to remove and hand over any HD in systems involved in the collection of data - which gets costly!
  16. 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...
  17. 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
  18. 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.
  19. 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.
  20. 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.
  21. 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.
  22. 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.
  23. 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.
  • Create New...

Important Information

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