All Activity

Has anyone found the solution to @gyc problem? I have a similar problem. I modified the config file as follows: [1-Wire] PortType=DS9490R PortType possible values=DS9097E, DS1410E, DS9097U or DS9480, DS9490R or DS9490B PortNumber=1 EnhancedOptions=Not use EnhancedOptions possible values=Not use, SESSION_INFINITE, SESSION_RSRC_RELEASE, SESSION_NO_FORCE_REG_SPD At the end, I would like to be able to read the volts from a sample via a DS28E17. Is this even possible with this?

The structure should be as follows: - PC talks via the DS9490R or RS232 to the DS28E17 - the latter transmits the 1-wire commands to the DS28E17 - The DS28E17 converts the commands into I2C and sends them to my test object - which in turn sends back the volts to be measured - the DS28E17 stores this in its internal memory - The memory with the value is read out via PC and adapter

I have an LDO for 3v3. The setup also works so far that I can read out the ROM, with the device-specific command 33h and directly via TMAX.

Thanks for your effort. And how it goings? The date of latest commit in Bitbucket is 2021-06-14. Have any new update? I am looking forward it.

RS232 has relatively high signal levels (+-9V) that would fry the DS28E17. You want a 1-Wire capable MCU or a USB adapter. It can be done with an Arduino.

I have only found this node, named Nifpga Discrete Transfer Function Direct.vi, but after inputting the transfer function coefficients, its output doesn't work correctly. I tried the same discrete transfer function on the non-FPGA side, and it worked fine. I am not sure what the issue is. Are there other methods to implement a discrete transfer function?

The function is there twice. It seems I also had to add the WaitForExit: To make it stable. Not sure if that what causes the crashes. The moment I add things, it seems stable, until a reload and then it crashes again

It should be a test of the DS28E17 and should be a 1-wire to I2C because I have no space on the board for I2C. I would like to be able to read out the whole thing via the PC, therefore RS232 or the DS9490R

You want to read out what voltage? How does RS232 fit into any of this? Why not go directly to I2C, which should be a more common interface?

Thanks Wiebe, good catch. Also note that this post pre-dates the release of the JKI .NET library. As always, the JKI product is very polished. I don't think they added the Ctrl-C command to the library yet though, but there is a request: https://www.vipm.io/posts/d078e550-5920-460f-8c12-a9dc547cdde4/

hi, I am fairly new to LabView and need help. I have a problem. I would like to communicate with the DS28E17 via 1-Wire, which converts the communication to I2C. Among other things, I would like to read out the voltage.I have tried it both via the DS9490R and via RS232. The TMEX library looks promising, but I can't find a datasheet for this either. In addition, I'm using LabView 2009, which doesn't make it much easier. I don't really have a first setup. Perhaps one of you has already dealt with this and could help me

To make this work on both 32 and 64 bit LabVIEW (I used LV23), the first parameter in SetConsoleCtrlHandler (in Kill.vi) should be a pointer sized integer:

I've attempted to create an account on the LabVIEW Wiki so I can start adding the presentations from GDevCon ANZ, but I can't due to some problem with my IP address. I'm just using my normal ISP so I have no idea why the Wiki is upset about the IP Cheers Brett User is blocked Your username or IP address has been automatically blocked by MediaWiki. The reason given is: Your IP address is listed as an open proxy in the DNSBL used by LabVIEW Wiki. Start of block: 04:55, 4 May 2024 Expiration of block: infinite Intended blockee: 203.30.15.150 Your current IP address is 203.30.15.150. Please include all above details in any queries you make. Return to Home.

yes, but ABSOLUTELY NOT! Really too expensive for my single user licence for few internal projects per year, so I decided to stop even the SSP renewal and stay with my perpetual licence. Maybe I have even the 2020 but all of my projects around the factory are with 2017, no need to upgrade since now...

It's Open Source (on SourceForge) and I started developping it more than 25 years ago. There never was any license involved but yes at that time Python 2.2 or thereabout was the actual version. I did some updates to also make it work in 2.3 and 2.5 and minor attempts to support 2.7 but had at that time lost interest in tinkering with it as I was getting more involved with Lua for LabVIEW and two scripting solutions next to each other seemed a bit excessive to work with. The shared library necessary to interface Python with LabVIEW definitely won't work out of the box with Python 3. There were simply to many changes with Python 3 to the internals as well as datatype system that that could work without some changes to the shared library interface code (the change to Unicode strings instead of ASCII is only one of them, but quite far reaching one). Also there is absolutely no support present for Python environments such as offered by Anaconda and the like. The main reason for starting with LabPython was actually that I had been trying to reverse engineer the script host interface that LabVIEW had introduced to interface to HiQ, and later Matlab. When searching for an existing scripting language that had an embedding interface to integrate into other applications to use as a test case, I came across a project called Python, that was still somewhat obscure at that time. I didn't particularly like Python, and that its inventor Guido van Rossum was actually Dutch did not affect my choice. And when reaching out to the Python community about how to embed Python in another application, I was frankly told that while there was an embedding API available in Python, there was little to no interest in supporting that and I was pretty much on my own trying to use that. It still seemed the most promising option as it was Open Source and had actually a real embedding API. I did not even come across Lua at that time, although before version 5.0 Lua had anyways fairly limited capabilities to integrate it in other applications. So I developed a Python script server for that interface to allow integration of Python, and even got help from someone from inside NI who was so friendly to give me the function prototype declarations that such an interface needed to support in order for LabVIEW to recognize the server and not crash when trying to load it. After it was done and started to work, I was less than thrilled by the fact that the script was actually a compile time resource, so could not be altered by the user of a LabVIEW application but only by its developer. As more of an afterthought, I added a programmatic interface to the already existing shared library and the main functionality of LabPython was born. As those old LabVIEW script nodes have been depreciated several years ago by NI, it would be definitely not a wise choice to try to build anything new based on that tech. Not even sure if LabVIEW 2023 and newer even would allow LabPython to be loaded as a script server. But its programmatic interface should be still usable, although for quite a few reasons not with Python 3 without some serious tinkering in the C code of the shared library interface.

I've been using OPC UA SDK for .NET - TRAEGER Docs which requires a developers license (one time or perpetual if you want updates) and is based on .NET They do have a GitHub repo with an OPC UA client example for LabVIEW --> opcuanet-samples/lv/Basic/Client at master · Traeger-GmbH/opcuanet-samples (github.com) For my project I implemented the server in .NET and utilize event callbacks and objects to pass data from/to the node manager. This works very well if you are familiar with the common pitfalls of calling external code in LV... Also looked at OPCFoundation/UA-.NETStandard: OPC Unified Architecture .NET Standard (github.com) which is free if you are a member of the OPC Foundation and OPCFoundation/UA-ModelCompiler: ModelCompiler converts XML files into C# and ANSI C (github.com) which is a code generator that turns XML Node Sets into C# / C code. Haven't worked much with it as my current solution works like a charm 🤷‍♂️ Have you considered upgrading? There is also OpenG LabPython Library Toolkit for LabVIEW - Download - VIPM by JKI. IIRC it required a license and I'm not sure if it works with Python 3 and newer versions of LabVIEW.

Gribo OK , i will look into reducing resolution , I should be ok with that ... Thanks Dan EDIT: GRIBO , i went to 4.5 resolution and i get the timing I need... i will have to make sure that the resolution is good , but , i guess i really dont have much choice .... this system is currently running by a program that was written in C++ , but we dont have the source code , and we need to get it converted to LV so we can add more types of units as needed ... Dan

Hello there! I am using a PCI-6110 DAQ and the purpose is to synchronize a DO with some AO.something like this: Now, im using AO/StartTrigger to trigger a DO,however,this works fine on PXIe-6341(another card for test),but unable to work on PCI-6110 there is an error -200077 and it asks me to change sampTimingType from SampTime to OnDemand,obvious there is no such thing in DAQmx Timing VI. Finally I choose to use a Timing Node to set sampTimingType as OnDemand, and a new error -200452 come. Is there a way to solve this problem? By the way,this VI would run on a LV2012 computer ,so some newer function may not work. Here I post a example VI : example.vi

Duplicate post from here: https://forums.ni.com/t5/LabVIEW/Read-from-INI-file-to-application-cluster/td-p/4369322

I am actually working on it but it is a bit more involved than I had anticipated at first. There is a certain impedance mismatch between what a library like open62541 offers as interface, and what LabVIEW needs to be able to properly interface to. I can currently connect to a server and query the available nodes, but querying the node values is quite a bit of work to adapt the strict LabVIEW type system to a more dynamic data type interface like what OPC UA offers. More advanced things like publish-subscribe are an even more involved thing to solve in a LabVIEW friendly way. And I haven't even started interfacing to the server side of of the library!

You want to create a scan list. At 10Hz, that's 160 relay close, stabilize, measure, relay open operations. You might have to sacrifice resolution to get to that speed.

I have an application where i need to scan up to 16 channels at 10Hz , using a 16 channel multiplexer card 34902A. i have tried a few simple things and am not close the 10 Hz , i saw somewhere either on here or NI.com about buffering , but , for the life of me i cant find it again. edit: i started with the advanced scan example. So , how do you set up buffering , and poll the instrument at regular intervals ? i did all the configuring outside of the while loop , and only triggered and read (into a queue) in the DAQ loop , but , it seems as though i am still a little shy of the 10Hz. Any pointers ? Dan

That's it! It didn't work for our use case as it can't really work around the issues of LabVIEW being unable to support two different platforms at the same time being loaded. As such it had not really significant advantages to the MGI Solution Builder in the way we had started using it.

That sounds like the LabVIEW Solution Builder, which I use. It works quite well.

Anyone interested in QUIC? I have a working client (OpenSSL doesn't support server-side ATM but will later this year). I feel I need to clarify that when I say I have a working client, that's without HTTP3 (just the QUIC transport). That means the "Example SSL Data Client" and "Example SSL HTTP Client TCP" can use QUIC but things like "Example SSL HTTP Client GET" cannot (for now). If you are interested, then now's the time to put in your use-cases, must haves and nice-to-haves. I'm particularly interested in the use-cases as QUIC has the concept of multiplexed streams so may benefit from a complete API (similar to how the SSH API has channels) rather than just choosing between TLS/DTLS/QUIC as it now operates.