Porter
-
Posts
231 -
Joined
-
Last visited
-
Days Won
27
Content Type
Profiles
Forums
Downloads
Gallery
Everything posted by Porter
-
Here are my results (Windows 7, LabVIEW 2015 32-bit): path constant average: 13.515us no path constant average: 13.437us path from control on front panel average: 13.958us (an attempt to simulate the V0.0.2 implementation) CLNbenchmark.vi
-
How about statically linking (not specifying path on diagram) and putting a conditional disable structure around each CLN? It is a pain to maintain but I think that it would give us the best performance. Also, when built to exe, the correct OS & bitness dll/so will be included automatically.
-
Modified version with mupGetExprVar fixed, path wired to CLNs, muParser dll moved to mupLib directory: muParser.zip Lets call it V0.0.2
-
Good catch. I missed that one. I was too distracted by my struggles with the getValueByPointer xnode (which does not work properly when built into an executable). Indeed, LabVIEW does not like an uninitialized parser reference. Now is it worth checking for hParser=0 in every mup vi? My plan was to create a wrapper for the mup VIs (muExpr class) to protect the end user from inadvertently crashing LabVIEW. Within that wrapper I make sure that the parser handle is properly initialized and pointers to variables are properly created/released.
-
Usually I would just build the library's path in a construct vi (this case it would be a mupCreate.vi) then pass it around in a cluster (or object) with the parser's handle. Is there a significant hit to the performance vs having a constant wired to the CLN?
-
Thanks for the 2015 version. I haven't yet make the jump to 2017. Waiting for SP1. I don't know why the pointer changed after passing through mupGetExprVar. I think that something is still wrong in the call setup for the varName parameter. The libmuparser.so files you provided, are they compiled from the modified source? Wondering this because the names are 2.2.4 and not 2.2.5
-
Thanks ensegre! I modified the muparser to include support for the not "!" operator (rather than writing another wrapper dll). I think that it is worth it. It was compiled for 32-bit and I'm using LV 2015 32-bit. I didn't consider adding Linux support as I don't have access to a copy of LabVIEW for Linux. I'll install LV 2017 today and take a look at your corrected version. I'm quite surprised about the DSDisposePtr crash. It was working on my system.
-
Anyone interested in trying this out?
-
Permission granted. Find it in the CR here: Looking forward to hearing your comments & suggestions. I'm sure that there are many things that can be done differently. So far I'm just happy that I stopped (frequently) crashing LabVIEW.
-
Version 3.0.0
406 downloads
LV-muParser provides a simple LabVIEW API for muParser fast math expression parser. A modified version of muParser v2.3.5 is included. You will find the muParser API in the functions palette under "Addons > LAVA > muParser" muParser: https://beltoforion.de/en/muparser/ LV-muParser source on github: https://github.com/rfporter/LV-muParser This package has been tested on Windows 10 & 11 and Ubuntu Linux 20.04. Documentation here: https://github.com/rfporter/LV-muParser/blob/c413686832caaff8179de923b388e21f9ca09161/Docs/LV-muParser User Guide.pdf-
- 1
-
-
- expression
- math
- (and 1 more)
-
View File LV muParser LV-muParser provides a simple LabVIEW API for muParser fast math expression parser. A modified version of muParser v2.3.4 is included. It will be installed to your "<LabVIEW>\resource" directory. I have added support for the "!" (not) operator as well as added ":" as a valid character for variable names. You will find the muParser API in the functions palette under "Addons > LAVA > muParser" muParser: https://beltoforion.de/en/muparser/ LV-muParser source on github: https://github.com/rfporter/LV-muParser This package has been tested on Windows 10 & 11 and Ubuntu Linux 20.04. Submitter Porter Submitted 08/25/2017 Category General License Type BSD (Most common)
-
I will ask permission from my employer to share the code on LAVA. I'll keep you posted.
-
Thanks again ned! DSNewPtr and MoveBlock did the trick. There is also a nice GetValueByPointer.xnode that really helps getting string values from pointers. muParser seems to be about 3x faster than the expression parser provided with labview and it supports logical operators.
-
Please try like this: Note that the default baud rate for the EM1200 is 19200 bps. Also note the 250ms delay between polls.
-
Hello Senthil, I would recommend trying the "MB_Master Comm Tester" (you can find this in LabVIEW's example finder) to test the communication with the device. This way you can just focus on the testing the serial port settings and register addresses before writing your own code.
-
I suspect that you've entered the address of 2000 in decimal format instead of hex 0x2000. Please check the radix of the "starting address" control. d = decimal, x=hex. 2000 in decimal format equals 0x07D0 in hex as indicated in the sent command 01 03 07 D0 00 01 84 87. Not sure why its reporting bad CRC instead of exception code 2: invalid data address (error 403462) but it might have something to do with how the E5CC handles a read request at address 0x07D0.
-
I would recommend trying the "MB_Master Comm Tester" (you can find this in example finder) to test the communication with the unit. This way you can just focus on the serial port settings and register addresses to start. I've successfully used the Plasmionique Modbus Master library to communicate with an Omron E5CN controller. By default, I think that the units are configured for 4-byte mode, so the temperature PV is located at holding register address 0 and the number of registers that you read should be 2. I also recommend that you start with a 1000ms timeout.
-
Have you taken a look at MuParser yet? http://beltoforion.de/article.php?a=muparser&p=interface
-
10ms seems like a very short polling period for a serial device. 100ms is more realistic. Of course it depends on baud rate, number of transactions, FIFO buffer settings etc... But yes, you can just poll the PLC in one loop (as shown in the simple serial example), then put the data into a queue or user event to pass it to other loops. I would recommend looking into the producer/consumer design pattern.
-
For #3, check the "MB_Master Simple Serial.vi" example located in "<LabVIEW>\examples\Plasmionique\MB Master\" or search for it in the Example Finder.
-
Please post your code, or send it to me via PM and I can take a look. #1, it would be very useful to know what error is reported when the read fails. #2, see attached. 0x8 is the low byte, 0x9 is the high-byte, the output is a single precision floating point number (32-bit) #3, it is very important to run "Close Session.vi" before exiting the program. This releases the lock on the serial port. Join registers to float.vi
-
I haven't run into this error yet with this Library. It seems to be generated when VISA can not access the serial port. http://digital.ni.com/public.nsf/allkb/6807113B057FDE4C86256B41008212ED Sounds like the first thing to try is close LabVIEW and reboot the computer.
-
Hello ASalcedo, Yes to both of your questions.
-
Version 1.2.1 is live on LabVIEW Tools Network. If you like our library, please consider leaving a review on the LVTN product page: http://sine.ni.com/nips/cds/view/p/lang/en/nid/214230
-
Thanks for the positive feedback I used to implement a centralized queued state machine for managing each comm port. Perhaps my approach was flawed, but one reason why I stopped doing that was because I found myself having to gut existing instrument drivers to adapt them to my framework (because the VISA resource was in the handler and the logic was in the device instance). By instead forcing VISA locks to behave (as I expected), I can just wrap the existing driver with my device instance. This also allows me to develop device code that is more portable (completely independent of my application's framework).
