From 11:00 PM CDT Friday, May 10 – 02:30 PM CDT Saturday, May 11 (04:00 AM UTC – 07:30 PM UTC), ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From 11:00 PM CDT Friday, May 10 – 02:30 PM CDT Saturday, May 11 (04:00 AM UTC – 07:30 PM UTC), ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
To download NI software, including the products shown below, visit ni.com/downloads.
Overview
This VI will cause a Princeton Applied Research Potentiostat (e.g. PAR 273A) to apply a potential to the working electrode, and it periodically update the counters which correspond to the Charge (coul), Total Applied Potential (mV) and Current (A). It is suitable for bulk electrolysis applications.re.
Description
Requirements
Software
LabVIEW 2012(or compatible)
NI-VISA
Additional Information or References
**This document has been updated to meet the current required format for the NI Code Exchange.**
Example code from the Example Code Exchange in the NI Community is licensed with the MIT license.
Thanks for another great piece of content!
I am using this on a Versastat II. It works once, but will no longer communicate with the potentiostat after I have hit stop. Any idea why this might happen?
After you hit stop, the program is no longer running. If you want to have a "pause" button, you can program a cell-on/cell-off toggle, but I didn't need that for my application. I usually just make a note of the charge that was passed through the solution and restart the program.
If it doesn't work after you restart, then there's a more fundamental problem with the GPIB communications...
M
yup, that is what I meant. I have to reset the potentiostat (physically turn it off, and turn on again) before the program will run a second time. If I do not do that, when I run the program again, it tells me I have a general GPIB I/O error. I will research that and see if I can nail down the problem. It may be something in MAX that I need to change. Thanks for the response. If you have any other thoughts, I am all ears.
I worked on this for a while today and I have uploaded the result. It should be downloadable within a day or so.
There is some improved error handling, but there is room for further improvement. The main problem seems to be that the potentiostat needs a little time to process a command and get output ready. If you attempt to read the output before it is ready then the system hangs. The problem is that the potentiostat says that it is ready before it actually is ready. I have added some delays here and there so that the problem with hanging is less prominent... I could not get the current version to hang, but that's no guarantee.
The new program uses "Send" and "Query" vi's that I described elsewhere... actually "Query2" seems a little more robust than the original, but there's still work to be done.
I hope this helps,
M
Excellent! Thanks for working on that. I had noticed it seemed to work better with a 10 sec delay instead of a 5 sec delay as well. I'll be curious to see your code. I have not had the time to work any more on it today, but am hoping to find some time to use this as subvi next week. Ideally I would want to output the current as a function of time to a graph/excel file. Since this does not require reading the coulumeter, it may work better this way. But again, I have still not had the time to put into it. I'll keep you updated.
Hi!
Current vs. time should not be difficult. You'll need to put something in the loop that generates a time index. I would route the current and time out of the while loop so they get indexed into an array and into a "save as spreadsheet file" (transposed). You might also connect the same data stream to a XY graph to preview the data. If you don't need charge or potential, I would delete the "query" vi's associated with READE and COUL... the "query" vi is where the instability creeps in.
Good luck!
Mike Shaw
First, thanks for taking the time to upload and support these. As someone who inherited a VersaStatII with no LabView experience, your .vi's have been extremely helpful.
It sounds like Photocurrent & I have essentially the same goal--to record E,I vs. time without bothering with curve acquisitions. My application will involve multi-week long experiments, so stability is the chief concern, specifically, handling the I/O Error6. Your QUERY2 subvi seems to have addressed this, nonetheless I was hoping you could enlighten me on 3 questions relevant to my future troubleshooting adventures.
First, you have the 2nd loop repeat if element 7 of the status array is true (Lockout State). I'm not familiar with the Lockout State, but should this be element 8, Operation Completed? It seems to work as is, so I'm probably wrong.
Second, have you messed with the GPIB Wait command? Ideally, this could replace the status while loops. But when I tried it, I'd eventually get Error 6, even with additional delays.
Third, could you clarify what the Interface Clear (Send IFC) command does? The time it takes for the potentiostat to freeze (in my own "query-less" vi) seems proportional to the length of the delay times, which makes me think something is accumulating in the pstats memory. Which makes no sense to me when I'm only using ReadE/ReadI commands. I'd like to add a routine command that clears all listen/talk signals without changing the existing settings (bias, etc.), hopefully preventing any "memory buildup" leading to Error6.
Thanks again for the great work,
Tim
Hi!
These are good questions! I will answer them in order.
>First, you have the 2nd loop repeat if element 7 of the status array is true
>(Lockout State). I'm not familiar with the Lockout State, but should this
>be element 8, Operation Completed? It seems to work as is, so I'm probably
>wrong.
The Potentiostat's status byte is slightly different than the standard GPIB
status byte. In this case status bit 7 is "output ready". Note that status
bit 7 is actually the 8th bit b/c bit 0 is "command done". If the GPIB
reads the potentiostat's output buffer before the output is ready, the
system will hang. The potentiostat is slow to respond, probably because it
is based on early 1990's technology (or earlier).
>Second, have you messed with the GPIB Wait command? Ideally, this could
>replace the status while loops. But when I tried it, I'd eventually get
>Error 6, even with additional delays
I've tried to stick with the potentiostat commands. In this case there is
also a potentiostat WAIT command which causes the potentiostat to pause in
data acquisition for a predefined amount of time. Unfortunately, when I
have inserted timed delays into my various programs, I still get the system
to hang. The potentiostat seems to prefer having its status polled and
having its output read within a short period after the output is ready. but
not before.
>Third, could you clarify what the Interface Clear (Send IFC) command does?
>The time it takes for the potentiostat to freeze (in my own "query-less" vi)
>seems proportional to the length of the delay times, which makes me think
>something is accumulating in the pstats memory.
I agree 100% with the behaviour you have observed. The longer that the
program runs, the more likely it is to hang. The extra checking in
Query2.vi extends the stability to at least a couple of hours, but I am not
sure about longer times. I also noticed that the old "query.vi" could be
run a certain number of times (within a range) and then the system would
hang.
I have not used the IFC command in my programs before. The manual says that
the potentiostat follows the IEEE standard for IFC, so it should just clear
the data on the GPIB and the potentiostat. I played with it a little for a
few minutes in my GPIB-CV program, and it did not seem to reset the
parameters to their defaults. It does take a finite time to run, so it
should be used in a loop which ends when the status byte indicates that the
IFC command is complete.
I will play with the IFC command myself in coming weeks. if it helps, I'll
introduce a "query3.vi" in my list of documents. Let me know how it works
in your application.
Best wishes,
Mike Shaw