Multiple test routines using a BS2 OEM board

Otaku1031 · 2012-11-07 11:42

Hi all,
I'm developing a system for testing small silicone catheter balloons (medical device components). The test involves inflating and deflating each balloon N times or until failure (burst). The system is simple - the BS2 controls a pneumatic solenoid that inflates the balloon until the balloon wall contacts a microswitch lever, shutting off the air flow. The program then waits a few seconds to allow the balloon to deflate. The cycle then repeats, until either the balloon fails or passes. In the event of a burst failure, a timeout will be coded to shut off the air flow after 10 seconds. The number of times the test is repeated is TBD right now.
Here's the question: I would like to be able to simultaneously test more than one balloon at a time. Each test fixture will have a separate solenoid and microswitch. If the balloon on test fixture A bursts, I want the testing to continue on fixture B until either that balloon passes or fails. Can this be done on a single BS2 or will I need to have two boards, each running an identical test program? All advice is appreciated.

Gary

davejames · 2012-11-07 12:02

Hi Otaku1031,

What level of control do you have over the inflation solenoid?

Otaku1031 · 2012-11-07 13:55

Hi davejames,
Pretty basic, just on/off. The actual air flow rate (both inflate and deflate) is controlled with a needle valve. The BS2 controls a relay which switches 110VAC to the solenoid. When the microswitch is closed (balloon deflated) the relay sends power to the solenoid, inflating the balloon. When the balloon contacts the lever and opens the switch, the relay shuts off the solenoid and allows the balloon to deflate. Rinse and repeat...

Sapphire · 2012-11-07 14:05

With the setup you described, a single BS2 should be able to control 8 balloons at once. There are 16 I/O pins, so you could use 8 outputs for the solenoids, and 8 inputs for the microswitches. The program could run all of them at once, setting bits in a byte as each balloon fills and clearing them as they deflate. Once one pops, that solenoid is not turned on again until the test is restarted. Use the Debug output to display status on a screen, and you could watch as the tests progress.

davejames · 2012-11-07 15:20

...yup - what Sapphire said.

Otaku1031 · 2012-11-07 21:09

Thanks, all. I'll have to educate myself on setting and clearing bits to monitor the test routines. I can write a routine that uses loops to inflate the balloon, monitor the switch status, allows deflating when the switch goes high and includes a timeout for capturing burst balloons. Problem is that this might only work for a single test fixture. I'll post code when I have a working routine. Oh, and I'm doing this on a BS2sx, not the OEM board as I first mentioned.

davejames · 2012-11-07 23:55

...consider on big loop that contains multiple blocks, each block containing the code to handle one balloon. Operation of these blocks would be governed by a variable that's tested at the beginning of the block. Conditions withing the block like, balloon-full or timeout-reached could set the variable such so that the big loop would ignore running the code block.

It makes sense...in my head anyway. It's midnight, it's been a long stressful day after pathetic election returns...and I'm going to bed.

Otaku1031 · 2012-11-08 08:13

Yep, that's what I'm thinking, too. More to come...

Otaku1031 · 2012-11-08 12:19

Ok, here's what works for a single channel test fixture. IN13 is the pin that is monitoring the microswitch state - when it goes high, the balloon deflates. P0 is controlling a relay that switches the 110VAC to the inflation solenoid. The 6s PAUSE timer is to allow the balloon to fully deflate before starting the next inflation cycle.

Test_balloon:
DO
IF (IN13 = 0) THEN 'check state of pin 13
HIGH 0 'turn on solenoid, inflate balloon until switch closes sending pin 13 high
DO
IF (IN13 = 1) THEN 'if high, shut off solenoid
LOW 0
PAUSE 6000 'allow balloon to deflate
GOTO Test_balloon 'repeat test
ENDIF
LOOP
ENDIF
LOOP
This routine will repeat ad infinitem, unless the balloon pops. The program stalls at that point because IN13 can't go high, but air still flows. I'm still working on how to insert a timeout function. I'm thinking that a FOR...NEXT loop, 50 iterations at 200ms per (total time 10s) bracketing the nested DO...LOOP would do the trick. If IN13 doesn't go high in 10s (plenty of time for the balloon to inflate), exit the loop. Additionally, I think I should be able to insert code for a second fixture into this framework, using different I/O pins, of course. Opinions are most welcome.

davejames · 2012-11-08 20:13

...looking forward to the acid test!

Otaku1031 · 2012-11-09 13:29

Ok, I got a routine that runs two (or more) test fixtures. They are running sequentially (alternating) right now, but I can live with that as the test just takes a few secs per. If a balloon pops on fixture A, the other continues testing although fixture A remains in the loop, same thing with fixture B. A popped balloon is assumed if the inflation monitoring switch doesn't go high after 10s, and that time is added to the A-B test cycle. If both balloons fail, the program halts.
So far, so good. Next up is extracting the number of cycles run per balloon leading up to a failure. Max number of test cycles is still TBD but will likely be ~50 cycles. I'll be looking at how best to use the DEBUG window to display cycle count results. Thanks to all for the pointers!

davejames · 2012-11-09 13:40

Gary...too cool! Glad to hear progress is being made.

A thought - do you have any way of detecting pressure?

I'm thinking that a working balloon will present a level of pressure in the feed line. Should that pressure drop below a set-point, one might assume presume that the balloon has ruptured.

You could forego the set number of loops for the timeout.

Otaku1031 · 2012-11-09 13:51

Hey Dave,
I did look at a pressure test initially. There is a LOT of variation among these balloons, some require just slightly over 2 psi to inflate, others take as much as 6 psi. I was considering using a pressure-activated switch to do the test until I started gathering the inflation pressure numbers. It seems to be due to very tiny variations in the wall thickness, I'm talking about just a couple thousandths of an inch. Since the supplier can't hold anything better than ± 0.002" we're stuck with it. In actual use, the inflation pressure is not an issue.

davejames · 2012-11-09 14:41

...hmmmmm - I guess I didn't convey my thought very well.

I was thinking down the path of checking for "is there pressure" vs "is there no pressure" as a quick means of detecting a ruptured balloon. That way, individual test sites could be shut down whilst the other sites continue. without incurring a multi-iteration-timeout loop.

Did that make sense?

Otaku1031 · 2012-11-09 15:16

Oh, I see what you meant. I do have some digital pressure meters here, but none of them have a way to access the pressure value (LCD only). I'd have to buy a sensor to do that test, and $$ is tight right now. I did add some code that looks at both timeout counters and skips either the A or B test sequence if the balloon has been determined to have failed on the previous cycle. That prevents repeating a doomed test, saves 10s per cycle if one of the balloons has popped.

davejames · 2012-11-09 21:14

...ok - you got it then. Good to hear!

Any chance of a video?

Otaku1031 · 2012-11-10 09:59

Sure. I'll post one on Monday.

Otaku1031 · 2012-11-12 09:02

Here's a link to a short video on Photobucket. The test rig is pretty crude, lots of clip leads, spit and baling wire. I'll be working in the machine shop this week to get everything mounted on an ABS baseplate and get the 110VAC connections covered. I'll probably still use the protoboard for the short term, I don't need it for anything else right now. Next step is to get the cycle counts displayed on a laptop. There's more switch positioning optimization needed to set the inflated balloon diameter.

http://s73.beta.photobucket.com/user/Otaku1031/media/Balloontester_1.mp4.html

Otaku1031 · 2012-11-12 10:47

Ok, next question. I would like to display the incrementing test results in the debug window for each of the balloons. What I need is a text line that says, for example, "Balloon test X" followed by the incrementing test number. Since I have two test fixtures I need to have both values displayed, on two separate lines in the debug window. I can get one of the test results to display and increment, but I'm getting some odd text in the window, seems to be a mix of hexadecimal and text. The PBasic Help doesn't really cover what I need to do. All advice is welcome.

davejames · 2012-11-12 10:55

Gary - thank you. I always find it interesting how/where the BS2 is being used.

And some of those other Halloween dealies are pretty spooky! What controller(s) did you use?

Otaku1031 wrote: »

Here's a link to a short video on Photobucket. The test rig is pretty crude, lots of clip leads, spit and baling wire. I'll be working in the machine shop this week to get everything mounted on an ABS baseplate and get the 110VAC connections covered. I'll probably still use the protoboard for the short term, I don't need it for anything else right now. Next step is to get the cycle counts displayed on a laptop. There's more switch positioning optimization needed to set the inflated balloon diameter.

http://s73.beta.photobucket.com/user/Otaku1031/media/Balloontester_1.mp4.html

davejames · 2012-11-12 10:55

...post your code? Or, at least the section in question.

Otaku1031 wrote: »

Ok, next question. I would like to display the incrementing test results in the debug window for each of the balloons. What I need is a text line that says, for example, "Balloon test X" followed by the incrementing test number. Since I have two test fixtures I need to have both values displayed, on two separate lines in the debug window. I can get one of the test results to display and increment, but I'm getting some odd text in the window, seems to be a mix of hexadecimal and text. The PBasic Help doesn't really cover what I need to do. All advice is welcome.

Otaku1031 · 2012-11-12 11:18

Hey Dave,
Here's the code. The part I'm having the issue with is in red text. This part of the code runs the inflation test for fixture A. Thanks!

test_1 VAR Byte

Test_balloon_1:
DO
IF counter = 50 THEN GOTO Test_balloon_2
IF (IN12 = 0) THEN
DO
HIGH 0
FOR counter = 1 TO 50
IF (IN12 = 1) THEN
LOW 0
PAUSE 5000
test_1 = test_1 + 1
DEBUG "Test 1 ", test_1
GOTO Test_balloon_2
ENDIF
PAUSE 200
IF counter = 50 THEN
LOW 0
IF counter = 50 AND counter1 = 50 THEN GOSUB Start
GOTO Test_balloon_2
ENDIF
NEXT
LOOP
ENDIF
LOOP

davejames · 2012-11-12 11:34

Otaku1031 wrote: »

Hey Dave,
Here's the code. The part I'm having the issue with is in red text. This part of the code runs the inflation test for fixture A. Thanks!

test_1 VAR Byte

Test_balloon_1:
DO
  IF counter = 50 THEN GOTO Test_balloon_2
    IF (IN12 = 0) THEN
      DO
         HIGH 0
         FOR counter = 1 TO 50
            IF (IN12 = 1) THEN
               LOW 0
               PAUSE 5000
[COLOR=#ff0000]            test_1 = test_1 + 1
               DEBUG "Test 1 ", test_1
[/COLOR]            GOTO Test_balloon_2
             ENDIF
             PAUSE 200
             IF counter = 50 THEN
               LOW 0
               IF counter = 50 AND counter1 = 50 THEN GOSUB Start
               GOTO Test_balloon_2
             ENDIF
          NEXT
     LOOP
  ENDIF
LOOP

...ahhhhh - change the DEBUG "Test 1", test_1 to DEBUG "Test 1", DEC2 test_1

The numbers being sent to the DEBUG window were probably interpreted as "unknown", so no output. Using the DEC2 formatter says "decimal numbers, 2 places please".

Look in the online help, or the Programming Reference manual in the chapter for DEBUG and you'll see all the related formatter info.

Otaku1031 · 2012-11-12 12:11

Yep, that did it. Thanks much! I added a CR after the DEC2 test_X so that the screen scrolls vertically when a new test result comes in. BTW, is there a way to simply update the incrementing value without having to create a new line on the DEBUG screen?

davejames · 2012-11-12 12:18

...yes there is, but you'll need the proper code (hex, decimal, or otherwise) for a plain carriage-return. The "CR" tells DEBUG to perform a carriage-return and line-feed.

I believe the DEBUG chapter I referenced earlier will note all the codes. The SEROUT chapter also, since these two commands are practically the same thing.

***Edit: OK, just looked in the reference manual and on page 168 you'll find a number of direct control-codes for navigating about the DEBUG output window - even in X/Y!

There is no code for a plain carriage-return - my bad. You could use the CRSRXY, or the individual CRSRX and CRSRY controls to manually place the cursor and just overwrite the test_1 value.

Otaku1031 · 2012-11-12 12:48

Hi Dave, I figured out how to do this. I used a DEBUG CLS on the line before the DEBUG "Test 1" and "Test 2" lines and added a second DEBUG line. When the first test result comes in, both the Test 1 and Test 2 descriptors are on the screen, followed by their respective values. The values update each time a test is run, I'm just rewriting the screen with each new test result. Works perfectly.
One last thing, the only way I can get the DEBUG window to open is to first do a CTRL R, then start the program using the momentary button (I'm running a loop that looks for P15 to go high to start the program). If I just start the program with the button, the DEBUG window doesn't open. I looked through the Help for something about how to get the window to pop without doing a CTRL R, but couldn't find anything. This is mostly a "nice to have" feature. I'm thinking I musta missed something in the Help file that talks about this...

davejames · 2012-11-12 13:03

...yeah, I've noticed the same thing about the Debug window only appearing on a first download/run. Subsequent starts of the program via the reset button do not open/utilize the Debug window. I've not heard of any way around this, other than use another form of output device like an LCD.

Glad to hear progress is being made.

Otaku1031 · 2012-11-12 13:23

Actually, since the laptop (with the Editor running) needs to be connected to the BS2sx anyway, it's not that much of a pain to just open and load the file each time I need to run a test series. Yes, an LCD would get around this and make the system completely stand-alone, but as I mentioned before the $ is tight right now and that ain't gonna happen. Bottom line is that the system works exactly as needed and it's just a matter of some fixture optimization now. Thanks very much for the insights and help - I learned a lot on this project.

davejames · 2012-11-12 13:54

...you're welcome Gary - glad to have been of some help. It was fun to watch this develop!

Keep in touch,

Dave

Sapphire · 2012-11-13 18:55

You can open a Debug window in the editor without having to download and run your program by clicking on the magnifying glass icon (to the right of the run icon) or by pressing Ctrl-D. Then you can use your momentary button to start the program.

Multiple test routines using a BS2 OEM board

Comments