Bulk Electrolysis with PAR potentiostat

[roadchem]

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

1. You should note the final charge which has passed through the cell.  You could easily modify the program to record time and charge in an array or spreadsheet file.
2. The charge is measured with an internal coulometer, not by integrating current.
3. This program turns on the external input of the potentiostat, thereby allowing the use of an external potential source in addition to the internal source in the potentiostat.
4. This allows the potential to be "dialed in" slowly... useful in cases where a potential overload occurs if you jump directly to the desired potential.
5. This should work for the Versastat 1, the PAR 263, the PAR 273A and similar potentiostats from Princeton Applied Research.
6. Previous and current (CHE 0911537) support by NSF is gratefully acknowledged for this work.
7. I have uploaded an updated set of vi's.  I haven't had time to make the code especially pretty, but there is some improved error handling, which hopefully will make the programs less prone to crashing when the potentiostat becomes unresponsive.  I will continue to work on these problems.

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.**

[Todd S.]

Thanks for another great piece of content!

[Photocurrent]

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?

[roadchem]

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

[Photocurrent]

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.

[roadchem]

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

[Photocurrent]

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.

[roadchem]

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

[tgeary]

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

[roadchem]

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