Microdrop software crashing?


#21

That looks like what happens when there is no signal getting to the feedback circuit. Use an oscilloscope to make sure that the hv signal from the amplifier is getting to the switching boards.

Another common problem that results in a graph like that is not connecting the red alligator clip to the test board.

-Ryan

···

On Tue, Mar 29, 2016 at 2:33 PM, Ryan Coghlan ryc...@gmail.com wrote:

I was busy with another project last week but am starting to troubleshoot my bot again now.

I built my power cable like the ‘B’ diagram, so it seems that at least my wiring should be correct… I just checked all the points on my control board and it seems they have the correct voltages according to the guide link posted below.

http://microfluidics.utoronto.ca/git/kicad___dmf_control_board.git/blob/refs/heads/master:/docs/Control%20board%20v2.1%20documentation.pdf

I am still getting the same test board results as before:

Not sure what to try next?

-Ryan C

On Monday, March 21, 2016 at 11:52:40 AM UTC-7, Manasi Raje wrote:

Hi Christian,

How big of a problem this could be? I have built the power cable in the A way. My signal generator boards are also acting up after the amplifier is turned ON. I am guessing that this is the reason.

Best,

-Manasi

On Saturday, March 19, 2016 at 8:05:34 AM UTC-7, Christian Fobel wrote:

Hi Ryan,

Regarding the signal generator power cord, the correct wiring is depicted by B in your diagram. I really like your drawing! I will add something like this to the construction wiki soon.

Thanks,

Christian

On Fri, Mar 18, 2016 at 5:43 PM Ryan Coghlan ryc...@gmail.com wrote:

Hi Ryan,

The sparking happened on the test chip only, and I replaced that with a backup. Hopefully the other boards are still working, I am in the process of testing each pad to see if the correct voltage is detected.

I had a question about the signal generator power cord assembly. The current directions are not very clear as to how to assemble the wires, I made a diagram of the wire assembly below with the orientation of the top wires shown by colored lines.

Which assembly diagram is correct for the signal generator power cord? I may have put this together wrong initially which could be causing the problems I am seeing.

Thanks,

-Ryan C

On Thursday, March 17, 2016 at 10:38:06 AM UTC-7, Ryan Fobel wrote:

Re: the amplifier gain, if auto-adjust-amplifier-gain is True, the system dynamically calculates the gain, so the value in that field on startup isn’t important (i.e., it will be adjusted to the proper value as soon as you activate an electrode).

By design, the gain defaults to 300 on startup, which is the highest possible gain for the standard Trek amplifier. This is the safest assumption to make when you don’t know the true gain, because the output voltage will initially be too low instead of too high.

I’m not sure what the problem is based on your graphs, but if you heard pops and smoke, it is likely that some of the components might be damaged. In general, I would start from the basics, make sure that the signal generator is working using an oscilloscope and try the HV boards connected one at a time. The test channel function is the safest thing to to run because it only uses 10V, which is less likely to cause damage than the other calibration procedures, which operate at >100V.

Another good habit to get into is checking for shorts between HV and GND on the switching boards, and +5V and GND on all boards before powering them up and/or applying high voltage.

Tracking down shorts/fried components can be a huge pain. I’ve spent many hours doing it… The good news is that once you get a system properly setup and calibrated, they tend to be pretty robust.

-Ryan

On Tue, Mar 15, 2016 at 8:15 PM, Ryan Coghlan ryc...@gmail.com wrote:

Hi Christian,

I went forward with the High Voltage reference load feedback calibration and the Device load calibration.

I ran the Device Load calibration twice, the first time I had some weird looking data so ran it again, and the test board started popping and sparking so I quickly tuned off the amplifier and saved my bot from damage. It is starting up fine today and I have extra test boards, I think I messed up a solder point on the first test board so I am thinking a bit of leftover flux made the board spark… Hopefully that doesn’t happen again! The first impedance test is shown below.

The High Voltage reference load feedback data is shown below: I am using the anti-alias shield - and I set my amplifier to 100v/v, should I be changing the amplifier gain setting to 100? It keeps resetting to 300, I am not sure why it is doing that.

I went and tried the test channel option again and now I get this result:

Thanks,

-Ryan C

On Saturday, March 12, 2016 at 9:19:39 AM UTC-8, Christian Fobel wrote:

Hi Ryan,

Please see my response inline below.

On Fri, Mar 11, 2016 at 6:35 PM Ryan Coghlan ryc…@gmail.com wrote:

I went and replaced the op-amp yesterday on the control board, and it seems to have fixed the ‘damaged channel 0,1’ errors. So that’s good! I also had a ground wire loose on the signal generator power cable so that may have caused a few problems as well.

After replacing the op-amp and re-attaching the wire the channel calibration started running properly, and I didn’t need to use the workaround program to bypass the current surge error.

Great to hear!

Unfortunately, I am still having the same problems with the channel testing. All four of my channel switching boards show a similar calibration to the picture posted below. It seems that channel 16 of all my boards creates a high response that slowly lowers as shown in the picture. I actually found a chunk of solder in one of my boards that was shorting one of the chips, so after removing that I figured the calibration would go through correctly but it seems that is not the case. I have checked over all of my boards with a dissecting scope and there are no visible shorts so I am not sure how to proceed with the assembly of my bot…

These results might be fine. They will likely improve significantly after performing calibration of the:

  • High-voltage reference load feedback
  • Device load feedback
    The High-voltage reference load feedback calibration ensures that the high-voltage signal coming out of the amplifier can be measured accurately by the control board across a wide range of frequencies. This is necessary, since the amplifier gain is not static across frequencies and loads (i.e., the number of actuated channels). The control board monitors the actual output of the amplifier and adjusts the input signal to the amplifier accordingly to maintain the target actuation voltage.

The Device load feedback calibration tries to minimize the error when measuring capacitance values across several orders of magnitude, with a wide range of actuation frequencies.

Please post screenshots or saved plots resulting from the High-voltage reference load feedback and Device load feedback calibrations. These will show us how your instrument is performing overall and identify any potential issues.

Thanks for your patience and determination. Good luck! :slight_smile:

Cheers,
Christian

On Wednesday, March 9, 2016 at 7:52:02 AM UTC-8, Christian Fobel wrote:

Hi Ryan,

Please see my response inline below.

On Tue, Mar 8, 2016 at 3:46 PM Ryan Coghlan rfco…@gmail.com wrote:

Hi Christian,

Thank you so much for creating a workaround, but I have it seems the command does not work:

Sorry, I just tested and found I had a typo in the command in my previous email. Please try to run:

C:\Users\rfc\Desktop\microdrop-1.0\python-2.7.9\python.exe -m pip install wheeler.dmf-control-board-firmware==1.1.post3.dev212538415

(Replaced - with == in package specifier.)

I am also getting a plugin crash error when I start MicroDrop, I don’t know if this is part of the test board crash problem but thought I would post it. I am also getting the ‘Channel 0,1 appear to be damaged’ error after this error displays, but I am using a new signal generator board and I am pretty sure it is in working order.

The error in the the dialog above seems to be distinct from the Channel 0,1 appear to be damaged, so I’ll address them separately.

The error dialog suggests that the file at C:\Users\rfc\Documents\Micrdrop\microdrop.ini could not be opened with write priveleges. Does this file exist? If so, can you open it, edit it (e.g., add a blank line) and try to save it?

Now for the Channel 0,1 appear to be damaged error. There is a section in the troubleshooting guide dedicated to this error. In our experience, this typically occurs when the op amps associated with one or both channels are damaged due to a surge of current. Typical causes of current surges in our experience include:

  • A short between two electrodes on a chip.
  • Connecting to the control board (happens upon launching Microdrop) with the amplifier turned on. (See here for more info.)
    Note that if the current limit was actually being exceeded while running (original error from this thread), the op amps could have been damaged as a result.

Cheers,
Christian

Thanks,

-Ryan

On Monday, March 7, 2016 at 7:38:56 PM UTC-8, Christian Fobel wrote:

Hi Ryan,

Sorry to hear you’re still encountering issues.

The error message shown in the image you included corresponds to the current limit being exceeded during actuation. In our experience, this typically is caused by a short or a misfunctioning photoMOS switch on one of the the switching boards. However, by the sound of it, your system was working ok prior to updating to the latest control board plugin.

To test if the hardware is working, I have compiled a custom version of the control board firmware with the current limit error detection disabled. While this should not be used as a long term solution, it should help to determine if there is, in fact, a short in the system, or if a software issue was introduced by the updated control board plugin.

To install custom control board firmware with over current disabled, run the following command (Microdrop must not be open):

C:\Users\rfc\Desktop\microdrop-1.0\python-2.7.9\python.exe -m pip install wheeler.dmf-control-board-firmware-1.1.post3.dev212538415

After running the above command, please launch Microdrop and try to run the "test channels" procedure.  Note that you should be prompted to flash the control board firmware due to a version mismatch (click yes).

Please let me know how you make out either way.

Thanks,

Christian​

On Fri, Mar 4, 2016 at 4:46 PM Ryan Coghlan rfc...@gmail.com wrote:

OK so I tested the workaround again, this time on my PC installed version of the portable MicroDrop program. It seems to have worked, and I can now open the MicroDrop software on my PC without needing to access it from a thumb drive. So my first issue of MicroDop crashing before opening has been resolved, so thank you for that workaround!

The second problem still remains however. Whenever I open the microdrop software and try to run the ‘test channel’ program (with only one board connected at a time) I get the same runtime error and must close out of MicroDrop. A picture of the error is shown below. I wasn’t having this problem with the older version of the plugin, just since last week.

Thanks,

-Ryan C

On Thursday, March 3, 2016 at 4:37:13 PM UTC-8, Ryan Coghlan wrote:

I tired the workaround and now I get a different error that I think says the requirements are already loaded.

Attached is the DOS error.

The channel test protocol still does not work and gives these same error as before.

-Ryan C

On Thursday, March 3, 2016 at 1:42:56 PM UTC-8, Christian Fobel wrote:

Hi Ryan,

I’m not sure of the root cause of the plugin issue, but I’ve seen this issue on a couple workstations in our lab as well.

As a workaround, try the following:

  1. Change directory into the dmf_control_board plugin directory after installing the plugin through the MicroDrop plugin manager dialog.
  2. Run the following command to update/install the requirements for the updated control board plugin:
C:\Users\rfc\Desktop\microdrop-1.0\python-2.7.9\python.exe -m pip install -r requirements.txt

  1. Start MicroDrop.
    This workaround has worked on the workstations here. Please let us know how you make out.

We’ll be looking into this issue and see if we can figure out how to fix the automatic update for the plugin.

Thanks,
Christian

On Tue, Mar 1, 2016 at 7:21 PM, Ryan Coghlan ryc...@gmail.com wrote:

Hello,

I have been using the MicroDrop portable version successfully for a while now until last Friday 2-26-16, but now it crashes every time I launch the application. It seems the newly updated dmf_control_board plugin seems to be the problem because when I delete the plugin the software loads correctly, but when I re-install the plugin the software fails every time.

I tried to upload the software to a new computer, and while the software loads fine with this new plugin version, I cannot run the channel test protocol without it freezing and giving me the error codes shown in the picture below.

So it seems I have two separate issues relating to the plugin update? Is anybody else having issues with this updated plugin?

Thanks

-Ryan C

You received this message because you are subscribed to the Google Groups “dropbot-dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to dropbot...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups “dropbot-dev” group.
To unsubscribe from this group and stop receiving emails from it, send an email to dropbot-dev...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.


#22

Ok so I just connected a scopemeter to my bot and here are the results:

When I turn the system on, this is the reading coming from the 'Out to amp" BNC:

When the ‘test channels’ program is running, the reading from the ‘Out to Amp’ reading changes to this:

And then using the voltage monitor BNC on the amplifier while the ‘test channels’ program is running, the voltage looks like this: (it does not look like the correct voltage is being applied for some reason)

In my amp is applying 100V/V gain, then doesn’t that mean the amp would put out ~212V with the current output set by the signal generator board in the second picture? I feel like it should only be at ~0.1V output if 10V were to be applied during the test channel program. I have not tested the output directly from the amp as I don’t want to fry my scope and/or myself if my signal generator board is set wrong.

-Ryan C

···

On Tuesday, March 29, 2016 at 11:48:20 AM UTC-7, Ryan Fobel wrote:

That looks like what happens when there is no signal getting to the feedback circuit. Use an oscilloscope to make sure that the hv signal from the amplifier is getting to the switching boards.

Another common problem that results in a graph like that is not connecting the red alligator clip to the test board.

-Ryan

On Tue, Mar 29, 2016 at 2:33 PM, Ryan Coghlan ryc...@gmail.com wrote:

I was busy with another project last week but am starting to troubleshoot my bot again now.

I built my power cable like the ‘B’ diagram, so it seems that at least my wiring should be correct… I just checked all the points on my control board and it seems they have the correct voltages according to the guide link posted below.

http://microfluidics.utoronto.ca/git/kicad___dmf_control_board.git/blob/refs/heads/master:/docs/Control%20board%20v2.1%20documentation.pdf

I am still getting the same test board results as before:

Not sure what to try next?

-Ryan C

On Monday, March 21, 2016 at 11:52:40 AM UTC-7, Manasi Raje wrote:

Hi Christian,

How big of a problem this could be? I have built the power cable in the A way. My signal generator boards are also acting up after the amplifier is turned ON. I am guessing that this is the reason.

Best,

-Manasi

On Saturday, March 19, 2016 at 8:05:34 AM UTC-7, Christian Fobel wrote:

Hi Ryan,

Regarding the signal generator power cord, the correct wiring is depicted by B in your diagram. I really like your drawing! I will add something like this to the construction wiki soon.

Thanks,

Christian

On Fri, Mar 18, 2016 at 5:43 PM Ryan Coghlan ryc...@gmail.com wrote:

Hi Ryan,

The sparking happened on the test chip only, and I replaced that with a backup. Hopefully the other boards are still working, I am in the process of testing each pad to see if the correct voltage is detected.

I had a question about the signal generator power cord assembly. The current directions are not very clear as to how to assemble the wires, I made a diagram of the wire assembly below with the orientation of the top wires shown by colored lines.

Which assembly diagram is correct for the signal generator power cord? I may have put this together wrong initially which could be causing the problems I am seeing.

Thanks,

-Ryan C

On Thursday, March 17, 2016 at 10:38:06 AM UTC-7, Ryan Fobel wrote:

Re: the amplifier gain, if auto-adjust-amplifier-gain is True, the system dynamically calculates the gain, so the value in that field on startup isn’t important (i.e., it will be adjusted to the proper value as soon as you activate an electrode).

By design, the gain defaults to 300 on startup, which is the highest possible gain for the standard Trek amplifier. This is the safest assumption to make when you don’t know the true gain, because the output voltage will initially be too low instead of too high.

I’m not sure what the problem is based on your graphs, but if you heard pops and smoke, it is likely that some of the components might be damaged. In general, I would start from the basics, make sure that the signal generator is working using an oscilloscope and try the HV boards connected one at a time. The test channel function is the safest thing to to run because it only uses 10V, which is less likely to cause damage than the other calibration procedures, which operate at >100V.

Another good habit to get into is checking for shorts between HV and GND on the switching boards, and +5V and GND on all boards before powering them up and/or applying high voltage.

Tracking down shorts/fried components can be a huge pain. I’ve spent many hours doing it… The good news is that once you get a system properly setup and calibrated, they tend to be pretty robust.

-Ryan

On Tue, Mar 15, 2016 at 8:15 PM, Ryan Coghlan ryc...@gmail.com wrote:

Hi Christian,

I went forward with the High Voltage reference load feedback calibration and the Device load calibration.

I ran the Device Load calibration twice, the first time I had some weird looking data so ran it again, and the test board started popping and sparking so I quickly tuned off the amplifier and saved my bot from damage. It is starting up fine today and I have extra test boards, I think I messed up a solder point on the first test board so I am thinking a bit of leftover flux made the board spark… Hopefully that doesn’t happen again! The first impedance test is shown below.

The High Voltage reference load feedback data is shown below: I am using the anti-alias shield - and I set my amplifier to 100v/v, should I be changing the amplifier gain setting to 100? It keeps resetting to 300, I am not sure why it is doing that.

I went and tried the test channel option again and now I get this result:

Thanks,

-Ryan C

On Saturday, March 12, 2016 at 9:19:39 AM UTC-8, Christian Fobel wrote:

Hi Ryan,

Please see my response inline below.

On Fri, Mar 11, 2016 at 6:35 PM Ryan Coghlan ryc…@gmail.com wrote:

I went and replaced the op-amp yesterday on the control board, and it seems to have fixed the ‘damaged channel 0,1’ errors. So that’s good! I also had a ground wire loose on the signal generator power cable so that may have caused a few problems as well.

After replacing the op-amp and re-attaching the wire the channel calibration started running properly, and I didn’t need to use the workaround program to bypass the current surge error.

Great to hear!

Unfortunately, I am still having the same problems with the channel testing. All four of my channel switching boards show a similar calibration to the picture posted below. It seems that channel 16 of all my boards creates a high response that slowly lowers as shown in the picture. I actually found a chunk of solder in one of my boards that was shorting one of the chips, so after removing that I figured the calibration would go through correctly but it seems that is not the case. I have checked over all of my boards with a dissecting scope and there are no visible shorts so I am not sure how to proceed with the assembly of my bot…

These results might be fine. They will likely improve significantly after performing calibration of the:

  • High-voltage reference load feedback
  • Device load feedback
    The High-voltage reference load feedback calibration ensures that the high-voltage signal coming out of the amplifier can be measured accurately by the control board across a wide range of frequencies. This is necessary, since the amplifier gain is not static across frequencies and loads (i.e., the number of actuated channels). The control board monitors the actual output of the amplifier and adjusts the input signal to the amplifier accordingly to maintain the target actuation voltage.

The Device load feedback calibration tries to minimize the error when measuring capacitance values across several orders of magnitude, with a wide range of actuation frequencies.

Please post screenshots or saved plots resulting from the High-voltage reference load feedback and Device load feedback calibrations. These will show us how your instrument is performing overall and identify any potential issues.

Thanks for your patience and determination. Good luck! :slight_smile:

Cheers,
Christian

On Wednesday, March 9, 2016 at 7:52:02 AM UTC-8, Christian Fobel wrote:

Hi Ryan,

Please see my response inline below.

On Tue, Mar 8, 2016 at 3:46 PM Ryan Coghlan rfco…@gmail.com wrote:

Hi Christian,

Thank you so much for creating a workaround, but I have it seems the command does not work:

Sorry, I just tested and found I had a typo in the command in my previous email. Please try to run:

C:\Users\rfc\Desktop\microdrop-1.0\python-2.7.9\python.exe -m pip install wheeler.dmf-control-board-firmware==1.1.post3.dev212538415

(Replaced - with == in package specifier.)

I am also getting a plugin crash error when I start MicroDrop, I don’t know if this is part of the test board crash problem but thought I would post it. I am also getting the ‘Channel 0,1 appear to be damaged’ error after this error displays, but I am using a new signal generator board and I am pretty sure it is in working order.

The error in the the dialog above seems to be distinct from the Channel 0,1 appear to be damaged, so I’ll address them separately.

The error dialog suggests that the file at C:\Users\rfc\Documents\Micrdrop\microdrop.ini could not be opened with write priveleges. Does this file exist? If so, can you open it, edit it (e.g., add a blank line) and try to save it?

Now for the Channel 0,1 appear to be damaged error. There is a section in the troubleshooting guide dedicated to this error. In our experience, this typically occurs when the op amps associated with one or both channels are damaged due to a surge of current. Typical causes of current surges in our experience include:

  • A short between two electrodes on a chip.
  • Connecting to the control board (happens upon launching Microdrop) with the amplifier turned on. (See here for more info.)
    Note that if the current limit was actually being exceeded while running (original error from this thread), the op amps could have been damaged as a result.

Cheers,
Christian

Thanks,

-Ryan

On Monday, March 7, 2016 at 7:38:56 PM UTC-8, Christian Fobel wrote:

Hi Ryan,

Sorry to hear you’re still encountering issues.

The error message shown in the image you included corresponds to the current limit being exceeded during actuation. In our experience, this typically is caused by a short or a misfunctioning photoMOS switch on one of the the switching boards. However, by the sound of it, your system was working ok prior to updating to the latest control board plugin.

To test if the hardware is working, I have compiled a custom version of the control board firmware with the current limit error detection disabled. While this should not be used as a long term solution, it should help to determine if there is, in fact, a short in the system, or if a software issue was introduced by the updated control board plugin.

To install custom control board firmware with over current disabled, run the following command (Microdrop must not be open):

C:\Users\rfc\Desktop\microdrop-1.0\python-2.7.9\python.exe -m pip install wheeler.dmf-control-board-firmware-1.1.post3.dev212538415

After running the above command, please launch Microdrop and try to run the "test channels" procedure.  Note that you should be prompted to flash the control board firmware due to a version mismatch (click yes).

Please let me know how you make out either way.

Thanks,

Christian​

On Fri, Mar 4, 2016 at 4:46 PM Ryan Coghlan rfc...@gmail.com wrote:

OK so I tested the workaround again, this time on my PC installed version of the portable MicroDrop program. It seems to have worked, and I can now open the MicroDrop software on my PC without needing to access it from a thumb drive. So my first issue of MicroDop crashing before opening has been resolved, so thank you for that workaround!

The second problem still remains however. Whenever I open the microdrop software and try to run the ‘test channel’ program (with only one board connected at a time) I get the same runtime error and must close out of MicroDrop. A picture of the error is shown below. I wasn’t having this problem with the older version of the plugin, just since last week.

Thanks,

-Ryan C

On Thursday, March 3, 2016 at 4:37:13 PM UTC-8, Ryan Coghlan wrote:

I tired the workaround and now I get a different error that I think says the requirements are already loaded.

Attached is the DOS error.

The channel test protocol still does not work and gives these same error as before.

-Ryan C

On Thursday, March 3, 2016 at 1:42:56 PM UTC-8, Christian Fobel wrote:

Hi Ryan,

I’m not sure of the root cause of the plugin issue, but I’ve seen this issue on a couple workstations in our lab as well.

As a workaround, try the following:

  1. Change directory into the dmf_control_board plugin directory after installing the plugin through the MicroDrop plugin manager dialog.
  2. Run the following command to update/install the requirements for the updated control board plugin:
C:\Users\rfc\Desktop\microdrop-1.0\python-2.7.9\python.exe -m pip install -r requirements.txt

  1. Start MicroDrop.
    This workaround has worked on the workstations here. Please let us know how you make out.

We’ll be looking into this issue and see if we can figure out how to fix the automatic update for the plugin.

Thanks,
Christian

On Tue, Mar 1, 2016 at 7:21 PM, Ryan Coghlan ryc...@gmail.com wrote:

Hello,

I have been using the MicroDrop portable version successfully for a while now until last Friday 2-26-16, but now it crashes every time I launch the application. It seems the newly updated dmf_control_board plugin seems to be the problem because when I delete the plugin the software loads correctly, but when I re-install the plugin the software fails every time.

I tried to upload the software to a new computer, and while the software loads fine with this new plugin version, I cannot run the channel test protocol without it freezing and giving me the error codes shown in the picture below.

So it seems I have two separate issues relating to the plugin update? Is anybody else having issues with this updated plugin?

Thanks

-Ryan C

You received this message because you are subscribed to the Google Groups “dropbot-dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to dropbot-dev...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups “dropbot-dev” group.
To unsubscribe from this group and stop receiving emails from it, send an email to dropbot-dev...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.


#23

Hi Christian,

I’m running Microdrop from the thumb drive version because I just couldn’t get the desktop version to work. I was having the same problem Christian was having with the plug in, where Microdrop worked before installing the dmf plug in. I tried your workaround which seemed to have worked. However, when I tried to open Microdrop it gives me the error shown in the picture and I’ve no clue what to do.

I would appreciate your help with this issue.

Thanks,

Pablo

···


#24

I figured out what was wrong with my DropBot a couple weeks ago and thought I would post to help anybody else having similar problems.

First thing that was wrong- a loose ground wire was causing intermittent ‘Analog channels [1,0] appear to be damaged’. Some times I would get the error, sometimes not. I connected the ground wire more securely and the issue stopped.

Second- as shown int he scopemeter pictures below I was getting the wrong voltages for certain setting. The issue here was that I didn’t understand how to read the scopemeter, and subtracted the voltage readings instead of adding them together - so I had calibrated my bot to produce 2V instead of 1V at rest.

Third - The channel readings were way off even after fixing these issues, basically showing the a reading as if the amplifier wasn’t on.

I figured out the problem was loose connections in my control board. When I had my boards created by Gold Phoenix they had a bunch of questions about the samtec through hole connector parts (picture below) parts and had issues ordering them, getting the parts shipped to their facility etc. so I just ordered these parts and added them to the mostly complete PCB’s. I was worried about the control board working, and the fact that I had two of them to test meant I simply put the parts through the PCB and plugged them into the Arduino without soldering them to the board. At first the boards all turned on just fine but after changing the control boards and fixing wires etc. I think adding and removing the connectors wore out the connection between the hole and the connectors, making the LED’s flicker and ultimately leading to my bot not working. After I figured out that both control boards were probably working fine and it was just bad connections that were causing problems I went ahead and soldered the connectors and what do you know the bot works as it should!

So in my experience with the DropBot assembly loose wired were the main cause of all my problems!

Now after fixing the wires my board calibrations did not look great yet, but adding the anti-alias chip and running through the high voltage and device load calibration steps leaves me with a functioning bot, with switching board results posted below.

-Ryan C

···

On Tuesday, March 29, 2016 at 12:49:07 PM UTC-7, Ryan Coghlan wrote:

Ok so I just connected a scopemeter to my bot and here are the results:

When I turn the system on, this is the reading coming from the 'Out to amp" BNC:

When the ‘test channels’ program is running, the reading from the ‘Out to Amp’ reading changes to this:

And then using the voltage monitor BNC on the amplifier while the ‘test channels’ program is running, the voltage looks like this: (it does not look like the correct voltage is being applied for some reason)

In my amp is applying 100V/V gain, then doesn’t that mean the amp would put out ~212V with the current output set by the signal generator board in the second picture? I feel like it should only be at ~0.1V output if 10V were to be applied during the test channel program. I have not tested the output directly from the amp as I don’t want to fry my scope and/or myself if my signal generator board is set wrong.

-Ryan C

On Tuesday, March 29, 2016 at 11:48:20 AM UTC-7, Ryan Fobel wrote:

That looks like what happens when there is no signal getting to the feedback circuit. Use an oscilloscope to make sure that the hv signal from the amplifier is getting to the switching boards.

Another common problem that results in a graph like that is not connecting the red alligator clip to the test board.

-Ryan

On Tue, Mar 29, 2016 at 2:33 PM, Ryan Coghlan ryc...@gmail.com wrote:

I was busy with another project last week but am starting to troubleshoot my bot again now.

I built my power cable like the ‘B’ diagram, so it seems that at least my wiring should be correct… I just checked all the points on my control board and it seems they have the correct voltages according to the guide link posted below.

http://microfluidics.utoronto.ca/git/kicad___dmf_control_board.git/blob/refs/heads/master:/docs/Control%20board%20v2.1%20documentation.pdf

I am still getting the same test board results as before:

Not sure what to try next?

-Ryan C

On Monday, March 21, 2016 at 11:52:40 AM UTC-7, Manasi Raje wrote:

Hi Christian,

How big of a problem this could be? I have built the power cable in the A way. My signal generator boards are also acting up after the amplifier is turned ON. I am guessing that this is the reason.

Best,

-Manasi

On Saturday, March 19, 2016 at 8:05:34 AM UTC-7, Christian Fobel wrote:

Hi Ryan,

Regarding the signal generator power cord, the correct wiring is depicted by B in your diagram. I really like your drawing! I will add something like this to the construction wiki soon.

Thanks,

Christian

On Fri, Mar 18, 2016 at 5:43 PM Ryan Coghlan ryc...@gmail.com wrote:

Hi Ryan,

The sparking happened on the test chip only, and I replaced that with a backup. Hopefully the other boards are still working, I am in the process of testing each pad to see if the correct voltage is detected.

I had a question about the signal generator power cord assembly. The current directions are not very clear as to how to assemble the wires, I made a diagram of the wire assembly below with the orientation of the top wires shown by colored lines.

Which assembly diagram is correct for the signal generator power cord? I may have put this together wrong initially which could be causing the problems I am seeing.

Thanks,

-Ryan C

On Thursday, March 17, 2016 at 10:38:06 AM UTC-7, Ryan Fobel wrote:

Re: the amplifier gain, if auto-adjust-amplifier-gain is True, the system dynamically calculates the gain, so the value in that field on startup isn’t important (i.e., it will be adjusted to the proper value as soon as you activate an electrode).

By design, the gain defaults to 300 on startup, which is the highest possible gain for the standard Trek amplifier. This is the safest assumption to make when you don’t know the true gain, because the output voltage will initially be too low instead of too high.

I’m not sure what the problem is based on your graphs, but if you heard pops and smoke, it is likely that some of the components might be damaged. In general, I would start from the basics, make sure that the signal generator is working using an oscilloscope and try the HV boards connected one at a time. The test channel function is the safest thing to to run because it only uses 10V, which is less likely to cause damage than the other calibration procedures, which operate at >100V.

Another good habit to get into is checking for shorts between HV and GND on the switching boards, and +5V and GND on all boards before powering them up and/or applying high voltage.

Tracking down shorts/fried components can be a huge pain. I’ve spent many hours doing it… The good news is that once you get a system properly setup and calibrated, they tend to be pretty robust.

-Ryan

On Tue, Mar 15, 2016 at 8:15 PM, Ryan Coghlan ryc...@gmail.com wrote:

Hi Christian,

I went forward with the High Voltage reference load feedback calibration and the Device load calibration.

I ran the Device Load calibration twice, the first time I had some weird looking data so ran it again, and the test board started popping and sparking so I quickly tuned off the amplifier and saved my bot from damage. It is starting up fine today and I have extra test boards, I think I messed up a solder point on the first test board so I am thinking a bit of leftover flux made the board spark… Hopefully that doesn’t happen again! The first impedance test is shown below.

The High Voltage reference load feedback data is shown below: I am using the anti-alias shield - and I set my amplifier to 100v/v, should I be changing the amplifier gain setting to 100? It keeps resetting to 300, I am not sure why it is doing that.

I went and tried the test channel option again and now I get this result:

Thanks,

-Ryan C

On Saturday, March 12, 2016 at 9:19:39 AM UTC-8, Christian Fobel wrote:

Hi Ryan,

Please see my response inline below.

On Fri, Mar 11, 2016 at 6:35 PM Ryan Coghlan ryc…@gmail.com wrote:

I went and replaced the op-amp yesterday on the control board, and it seems to have fixed the ‘damaged channel 0,1’ errors. So that’s good! I also had a ground wire loose on the signal generator power cable so that may have caused a few problems as well.

After replacing the op-amp and re-attaching the wire the channel calibration started running properly, and I didn’t need to use the workaround program to bypass the current surge error.

Great to hear!

Unfortunately, I am still having the same problems with the channel testing. All four of my channel switching boards show a similar calibration to the picture posted below. It seems that channel 16 of all my boards creates a high response that slowly lowers as shown in the picture. I actually found a chunk of solder in one of my boards that was shorting one of the chips, so after removing that I figured the calibration would go through correctly but it seems that is not the case. I have checked over all of my boards with a dissecting scope and there are no visible shorts so I am not sure how to proceed with the assembly of my bot…

These results might be fine. They will likely improve significantly after performing calibration of the:

  • High-voltage reference load feedback
  • Device load feedback
    The High-voltage reference load feedback calibration ensures that the high-voltage signal coming out of the amplifier can be measured accurately by the control board across a wide range of frequencies. This is necessary, since the amplifier gain is not static across frequencies and loads (i.e., the number of actuated channels). The control board monitors the actual output of the amplifier and adjusts the input signal to the amplifier accordingly to maintain the target actuation voltage.

The Device load feedback calibration tries to minimize the error when measuring capacitance values across several orders of magnitude, with a wide range of actuation frequencies.

Please post screenshots or saved plots resulting from the High-voltage reference load feedback and Device load feedback calibrations. These will show us how your instrument is performing overall and identify any potential issues.

Thanks for your patience and determination. Good luck! :slight_smile:

Cheers,
Christian

On Wednesday, March 9, 2016 at 7:52:02 AM UTC-8, Christian Fobel wrote:

Hi Ryan,

Please see my response inline below.

On Tue, Mar 8, 2016 at 3:46 PM Ryan Coghlan rfco…@gmail.com wrote:

Hi Christian,

Thank you so much for creating a workaround, but I have it seems the command does not work:

Sorry, I just tested and found I had a typo in the command in my previous email. Please try to run:

C:\Users\rfc\Desktop\microdrop-1.0\python-2.7.9\python.exe -m pip install wheeler.dmf-control-board-firmware==1.1.post3.dev212538415

(Replaced - with == in package specifier.)

I am also getting a plugin crash error when I start MicroDrop, I don’t know if this is part of the test board crash problem but thought I would post it. I am also getting the ‘Channel 0,1 appear to be damaged’ error after this error displays, but I am using a new signal generator board and I am pretty sure it is in working order.

The error in the the dialog above seems to be distinct from the Channel 0,1 appear to be damaged, so I’ll address them separately.

The error dialog suggests that the file at C:\Users\rfc\Documents\Micrdrop\microdrop.ini could not be opened with write priveleges. Does this file exist? If so, can you open it, edit it (e.g., add a blank line) and try to save it?

Now for the Channel 0,1 appear to be damaged error. There is a section in the troubleshooting guide dedicated to this error. In our experience, this typically occurs when the op amps associated with one or both channels are damaged due to a surge of current. Typical causes of current surges in our experience include:

  • A short between two electrodes on a chip.
  • Connecting to the control board (happens upon launching Microdrop) with the amplifier turned on. (See here for more info.)
    Note that if the current limit was actually being exceeded while running (original error from this thread), the op amps could have been damaged as a result.

Cheers,
Christian

Thanks,

-Ryan

On Monday, March 7, 2016 at 7:38:56 PM UTC-8, Christian Fobel wrote:

Hi Ryan,

Sorry to hear you’re still encountering issues.

The error message shown in the image you included corresponds to the current limit being exceeded during actuation. In our experience, this typically is caused by a short or a misfunctioning photoMOS switch on one of the the switching boards. However, by the sound of it, your system was working ok prior to updating to the latest control board plugin.

To test if the hardware is working, I have compiled a custom version of the control board firmware with the current limit error detection disabled. While this should not be used as a long term solution, it should help to determine if there is, in fact, a short in the system, or if a software issue was introduced by the updated control board plugin.

To install custom control board firmware with over current disabled, run the following command (Microdrop must not be open):

C:\Users\rfc\Desktop\microdrop-1.0\python-2.7.9\python.exe -m pip install wheeler.dmf-control-board-firmware-1.1.post3.dev212538415

After running the above command, please launch Microdrop and try to run the "test channels" procedure.  Note that you should be prompted to flash the control board firmware due to a version mismatch (click yes).

Please let me know how you make out either way.

Thanks,

Christian​

On Fri, Mar 4, 2016 at 4:46 PM Ryan Coghlan rfc...@gmail.com wrote:

OK so I tested the workaround again, this time on my PC installed version of the portable MicroDrop program. It seems to have worked, and I can now open the MicroDrop software on my PC without needing to access it from a thumb drive. So my first issue of MicroDop crashing before opening has been resolved, so thank you for that workaround!

The second problem still remains however. Whenever I open the microdrop software and try to run the ‘test channel’ program (with only one board connected at a time) I get the same runtime error and must close out of MicroDrop. A picture of the error is shown below. I wasn’t having this problem with the older version of the plugin, just since last week.

Thanks,

-Ryan C

On Thursday, March 3, 2016 at 4:37:13 PM UTC-8, Ryan Coghlan wrote:

I tired the workaround and now I get a different error that I think says the requirements are already loaded.

Attached is the DOS error.

The channel test protocol still does not work and gives these same error as before.

-Ryan C

On Thursday, March 3, 2016 at 1:42:56 PM UTC-8, Christian Fobel wrote:

Hi Ryan,

I’m not sure of the root cause of the plugin issue, but I’ve seen this issue on a couple workstations in our lab as well.

As a workaround, try the following:

  1. Change directory into the dmf_control_board plugin directory after installing the plugin through the MicroDrop plugin manager dialog.
  2. Run the following command to update/install the requirements for the updated control board plugin:
C:\Users\rfc\Desktop\microdrop-1.0\python-2.7.9\python.exe -m pip install -r requirements.txt

  1. Start MicroDrop.
    This workaround has worked on the workstations here. Please let us know how you make out.

We’ll be looking into this issue and see if we can figure out how to fix the automatic update for the plugin.

Thanks,
Christian

On Tue, Mar 1, 2016 at 7:21 PM, Ryan Coghlan ryc...@gmail.com wrote:

Hello,

I have been using the MicroDrop portable version successfully for a while now until last Friday 2-26-16, but now it crashes every time I launch the application. It seems the newly updated dmf_control_board plugin seems to be the problem because when I delete the plugin the software loads correctly, but when I re-install the plugin the software fails every time.

I tried to upload the software to a new computer, and while the software loads fine with this new plugin version, I cannot run the channel test protocol without it freezing and giving me the error codes shown in the picture below.

So it seems I have two separate issues relating to the plugin update? Is anybody else having issues with this updated plugin?

Thanks

-Ryan C

You received this message because you are subscribed to the Google Groups “dropbot-dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to dropbot-dev...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups “dropbot-dev” group.
To unsubscribe from this group and stop receiving emails from it, send an email to dropbot-dev...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.