It's been a long time since I've looked at it, but if you've calculated your new x and y values, you should just be able to put them into the setcursorpos block. I've attached the SetCursorPosition.vi with some additional vi s to simulate what I was trying to do. You should be able to take that and do what you need to do.
Regards,
John
Can you post your code?
Yep
As mentioned above, use the LabVIEW driver.
I happen to know offhand that this device always returns voltage,current from a read. So you're going to get current every time you index element 1 from your reading array. Voltage is at index 0.
wrote: I did a linear fit that estimates he'll be back here at 1:13 AM, September 1st 2021.
Dear future Hooovahh, do you still derail forum conversations for the sake of humor? And did forum subscriptions (like this one) migrate in the 1 or 2 forum overhauls NI has likely done in that time?
Do you have error handing going on? If the insert fails it will generate an error and tell you why. In my cases 90% of the time I just have the front panel open already. To make this more robust you can capture this and close the front panel then attempt another insert. You may want to look up some subpanel examples on the forums, or make a new thread if you are still having issues.
wiebe basically said it all. Crosspost to your other thread BTW.
XNodes are highly experimental, undocumented, and NI does not want you or anyone outside of NI creating them. They are on your palette already and NI makes several which are super useful, but without proper testing and documentation you are likely going to spend alot of time going in circles. Still I enjoy them and presented on them a couple times.
Newer NI Week Presentation (less examples but talks about VIMs)
I too would highly recommend you look into VIMs first. They have type adaption and are officially supported. While XNodes can do lots more than type adaption, that is probably the most common use for them.
Hello,
I am currently developing a test program for a customer and I need to determine if the UUT is recognised and listed in device manager when attached to the PC via USB cable.
I have tried to use the SystemExec VI and call devcon.exe using the devcon find * command, but nothing is returned via the standard output string. I have since found out that this id due to it needing to run with administrative privileges.
I found an article where it was suggested that listing all attached devices could achieved using the Call Library Function and point it to C:\Windows\System32\devmgr.dll
Unfortunately I'm not to sure what I am doing with the function and the article didn't really go into any depth of how it would be done.
Could anybody shed any light on how best to go about listing all attached devices. I didn't expect to be as difficult as it appears to be!
Thanks for looking,
Iain
wrote:
Yes, every CLD exam can be successfully implemented as a simple state machine.
No state machine is ever simple. Or at least they are a big pain to me. If everything is right the first time, it's ok, but usually, and especially during CLDs, it's not. Haven't use one in years. If I have to, I'll use a state pattern. And yes, I passed my CLD using one.
IIRC, there's usually something that needs to run in parallel? Of course you can make a SM, with a demon\actor-ish conrtuct, but then it wouldn't be simple anymore.
thanks for the answer and yes, I already did the exam examples, actually, that's why I did this question because all of the solutions in the examples are state machines
From what I am seeing, I would only have 1 look with an Event Structure. It can handle the writing to both of your instruments since it only happens when you push a button.
Now for the reading, I would have a loop for each of those. You can just use the global variables to hold the latest values. Then your logging loop can just grab the latest values (ie read the globals) every X amount of time (whatever you want your logging rate to be).
So I am counting 4 loops: User Interface, Read Instrument 1, Read Instrument 2, Logger.
Thanks I'll give it a try
wrote: thanks for the answer and yes, I already did the exam examples, actually, that's why I did this question because all of the solutions in the examples are state machines
Mind you, I wouldn't take those example solutions as a guide to how it's done. Last time I checked, the style was terrible. I hope they revised them, because as they where a few years ago, they shouldn't pass.
If you feel comfortable with a state machine, use a state machine.
Dear Sir/Mam, i am trying to read data from serial port and saving it to a text file, i have to create around million of files in a month but my vi is only able to generate around 30,000 to 40000 files and after that the system goes slow, the main problen is that the vi takes a longertime to create a txt file, so when i have a large data sets the vi becomes slow and when i change the folder location it start to work normal. can any one help me in this regard?
thanks
You almost answered yourself. 1 million files per month means about one file every 2 seconds.
Such a huge number of files is unmanageable. You should try to cluster data together, for example generating one file per hour. Into the file, different acquisitions would be properly separated by a "marker" line, reporting e.g. the acquisition start time.
If you really want to save one file per acquisition, separate groups of file into different folders. 1 folder per day would mean about 40000 files in one directory, which in my opinion is still too much.
Or consider using a database. One million files a month would b every manageable. How will you analyze the data? How will user's try to work with that many files. Either try to store fewer files containing more data or use a database.
You need to package your DB code into its own PPL that the other components will use. Otherwise each PPL will load its own copy of the DB code a which is most likely what is causing your crash.
While PPLs are a great tool they can complicate your life. Once you start using them you need have to fully commit since if you are using re-use libraries. PPLs will load their own copy of a library or set of VIs. Best case this just means that your application is using more memory. Wort case you get conflict, especially if any of your libraries need to maintain state since you end up with multiple copies. We switched to using PPLs about a year ago and we are now approaching 150 of them to make all of our reuse libraries work properly.
wrote: Best practice (IMHO): Avoid DVRs at all costs.
They are a pain, as they get disposed when the code stops running. So you can not debug sub VIs.
You talk a lot about why\why not to use DVRs. You should tell us what you want instead. Better jet: show us the design. OO Programming should be preceded by OO Analysis and OO Design, at least for best results.
If you want singleton behavior, I'd consider a private global in a class. It won't avoid race conditions, but at least the data is still there when you stop your code. It's all very dependent on the situation, so we need to know about that. You can also wrap the FGV in the class, but do make it private (or at least protected).
For me, a DVR in a class is a "by reference" pattern. You shouldn't use patterns (like an actor pattern
) as a solution to everything. Use when needed...
I think this is a bit of an extreme. DVRs are a valuable tool your the toolbox. They can be abused like any other thing can but they are also very useful. We use them often. For me the decision to using a by reference to a by value class comes down to what exactly am I representing and whether the wire might get branched. If I am representing a physical item in the real world I prefer to use DVRs if I need to maintain state information about that item. The last thing I want is to branch a wire somewhere and all of a sudden my nuclear reactor is both on and off at the same time because the branch effectively cloned my reactor and now I have two copies of it.
wrote: wrote: Best practice (IMHO): Avoid DVRs at all costs.
They are a pain, as they get disposed when the code stops running. So you can not debug sub VIs.
You talk a lot about why\why not to use DVRs. You should tell us what you want instead. Better jet: show us the design. OO Programming should be preceded by OO Analysis and OO Design, at least for best results.
If you want singleton behavior, I'd consider a private global in a class. It won't avoid race conditions, but at least the data is still there when you stop your code. It's all very dependent on the situation, so we need to know about that. You can also wrap the FGV in the class, but do make it private (or at least protected).
For me, a DVR in a class is a "by reference" pattern. You shouldn't use patterns (like an actor pattern
) as a solution to everything. Use when needed...
I think this is a bit of an extreme. DVRs are a valuable tool your the toolbox. They can be abused like any other thing can but they are also very useful. We use them often. For me the decision to using a by reference to a by value class comes down to what exactly am I representing and whether the wire might get branched. If I am representing a physical item in the real world I prefer to use DVRs if I need to maintain state information about that item. The last thing I want is to branch a wire somewhere and all of a sudden my nuclear reactor is both on and off at the same time because the branch effectively cloned my reactor and now I have two copies of it.
Sure, if you don't like debugging... And love those in placement structures.. DVRs are great.
How about OpenGDS by reference class if you want a by reference class? Last I heard, they are persistence, and you get by reference behavior for free. Will check that soon...
If you know that the Folder starts out empty and each file name is incremented by one, generate the file name yourself, keeping track of the current number. You can use a file name format e.g. as "FILE%010d.dat" or "FILE%010x.dat" or similar. Even if the folder already has some files, it would be trivial to determine the highest suffix once before the program starts and then keep incrementing from there. Alternatively, you could e.g. format the current time stamp into a filename (guaranteed to be unique and sorted, if done correctly).
The tool "Create file name with incrementing suffix" Is the only thing that is holding you back, because with every call it does a "list folder" command, which gets more and more expensive as the number of files increases. Listing tens of thousands of file names to sort out what number comes next is not a trivial operation the way it is implemented. (You can open it to see what it does!).
Still, as the others above, I question the sanity of this approach overall. There are probably better ways to do all that than using the file system to segment data into tiny aliquots.
) as a solution to everything. Use when needed...