Microdrop software crashing?


#1

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


#2

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.


#3

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.


#4

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.


#5

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​

<details class='elided'>
<summary title='Show trimmed content'>&#183;&#183;&#183;</summary>

On Fri, Mar 4, 2016 at 4:46 PM Ryan Coghlan <rfco...@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

> 

> [<img src="https://lh3.googleusercontent.com/-Ftkc5RQWPSQ/VtoCElIKfSI/AAAAAAAAAkQ/3-I1lZA-NFU/s320/test%2Bchannel%2Berror.jpg" border="0" width="320" height="240">](https://lh3.googleusercontent.com/-Ftkc5RQWPSQ/VtoCElIKfSI/AAAAAAAAAkQ/3-I1lZA-NFU/s1600/test%2Bchannel%2Berror.jpg)

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

> > 

> > [<img src="https://lh3.googleusercontent.com/-eRcvm-G3c30/VtjYsz1bCVI/AAAAAAAAAj4/rnFYSdkeT3k/s320/dmf%2Bplugin%2Berror.jpg" border="0" width="243" height="320">](https://lh3.googleusercontent.com/-eRcvm-G3c30/VtjYsz1bCVI/AAAAAAAAAj4/rnFYSdkeT3k/s1600/dmf%2Bplugin%2Berror.jpg)

> > -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.
> > > 1. 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](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](https://groups.google.com/d/optout).

</details>

#6

Hi Christian,

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

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.

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.


#7

worked for me happy

···

Am Donnerstag, 3. März 2016 22:42:56 UTC+1 schrieb Christian Fobel:

  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.

#8

Hi Ryan,

Please see my response inline below.

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

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​

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

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

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

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

···

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

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

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

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

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

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


#9

I am facing the same problem. I was facing another problem (talking about it in a different post) with Microdrop crashing before which I was only avoiding the update. When I encountered a different problem, I tried to re-install Microdrop and then I had to update the control board plugin. After updating that plugin I got a similar error and Microdrop did not open.
I tried Christian’s workaround but I am getting a similar error message. (attached a picture of that) I am not sure how Ryan Coghlan got it to work.

Any help would be really appreciated!

Best,

-Manasi

···

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.

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.


#10

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.

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…

···

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.

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.


#11

I think I went and deleted the old plugin files from the plugin file, re-downloaded and installed the dfm_control_board plugin, and then ran the script above. I am also running the MicroDrop software from both a memory stick and the internal hard drive on my computer, so if one version stops working for whatever reason I use the other. I also switch between the MicroDrop and MicroDrop_installed .exe files within the MicroDrop 1.0 directory, so in reality I am running one of 4 programs until one of them works…

-Ryan C

···

On Friday, March 11, 2016 at 3:07:53 PM UTC-8, Manasi Raje wrote:

I am facing the same problem. I was facing another problem (talking about it in a different post) with Microdrop crashing before which I was only avoiding the update. When I encountered a different problem, I tried to re-install Microdrop and then I had to update the control board plugin. After updating that plugin I got a similar error and Microdrop did not open.
I tried Christian’s workaround but I am getting a similar error message. (attached a picture of that) I am not sure how Ryan Coghlan got it to work.

Any help would be really appreciated!

Best,

-Manasi

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.

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.


#12

Hi Manasi,

Looking at your screenshot, it looks like you might have just missed the first step (i.e., changing into the dmf_control_board_plugin directory).

Just to clarify, please try the following steps:

  1. Change directory into the dmf_control_board plugin directory after installing the plugin through the MicroDrop plugin manager dialog.
  • **From your screenshot, it looks like you are running the installed version of Microdrop. In this case, the ****dmf_control_board**directory should be in C:\Users\<your username>\Documents\Microdrop\plugins\dmf_control_board
  • Run the following command to update/install the requirements for the updated control board plugin:
  • C:\Users\<your username>\Documents\Microdrop\plugins\dmf_control_board> "C:\Program files (x86)\Microdrop\python-2.7.9\python.exe" -m pip install -r requirements.txt
    
    
  • Start MicroDrop.

Please let me know how you make out.

Cheers,
Christian

···

On Fri, Mar 11, 2016, 6:07 PM Manasi Raje manas...@lbl.gov wrote:

I am facing the same problem. I was facing another problem (talking about it in a different post) with Microdrop crashing before which I was only avoiding the update. When I encountered a different problem, I tried to re-install Microdrop and then I had to update the control board plugin. After updating that plugin I got a similar error and Microdrop did not open.
I tried Christian’s workaround but I am getting a similar error message. (attached a picture of that) I am not sure how Ryan Coghlan got it to work.

Any help would be really appreciated!

Best,

-Manasi

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


#13

Hi Ryan,

Please see my response inline below.

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

Hi Ryan,

Please see my response inline below.

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

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​

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

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

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

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

···

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

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

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

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

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

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

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

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


#14

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.

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.


#15

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


#16

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.

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.

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.


#17

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


#18

Hi Christian,

Thanks for the clarification! It didn’t work out for me… However, I deleted the new plugins and I am using the old files now.

···

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

Hi Manasi,

Looking at your screenshot, it looks like you might have just missed the first step (i.e., changing into the dmf_control_board_plugin directory).

Just to clarify, please try the following steps:

  1. Change directory into the dmf_control_board plugin directory after installing the plugin through the MicroDrop plugin manager dialog.
  • **From your screenshot, it looks like you are running the installed version of Microdrop. In this case, the ****dmf_control_board**directory should be in C:\Users\<your username>\Documents\Microdrop\plugins\dmf_control_board
  • Run the following command to update/install the requirements for the updated control board plugin:
  • C:\Users\<your username>\Documents\Microdrop\plugins\dmf_control_board> "C:\Program files (x86)\Microdrop\python-2.7.9\python.exe" -m pip install -r requirements.txt
    
    
  • Start MicroDrop.

Please let me know how you make out.

Cheers,
Christian

On Fri, Mar 11, 2016, 6:07 PM Manasi Raje mana...@lbl.gov wrote:

I am facing the same problem. I was facing another problem (talking about it in a different post) with Microdrop crashing before which I was only avoiding the update. When I encountered a different problem, I tried to re-install Microdrop and then I had to update the control board plugin. After updating that plugin I got a similar error and Microdrop did not open.
I tried Christian’s workaround but I am getting a similar error message. (attached a picture of that) I am not sure how Ryan Coghlan got it to work.

Any help would be really appreciated!

Best,

-Manasi

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.

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.


#19

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.

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.

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.


#20

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.