Bravo not dropping tips

Hello, I have a Bravo that doesn't always drop all the tips when ejecting. Is it possible to make it do the eject tips command twice?

Parents
  • Thank you for reaching out with your Bravo question.

    The below suggestions are based on VWorks 14.2 when using a Bravo with a 96LT head, but we expect the behavior to be the same when running the system through other VWorks versions with either a 96LT, 96ST, and 384ST heads. 

    It is possible to have the tips off task occur twice in a row in VWorks. However, this will trigger a compiler error in the software stating that it is trying to perform tips off when there are no tips on the head.  An administrator level VWorks user could run the protocol despite these compiler errors and there are no physical issues that will occur as a result of this change so it would be possible to test this solution to see if it resolves the tips off problem.

    It may be necessary to work around the compiler errors if this modification resolves the error and will stay in place. Specifically, it will be necessary if there are users with Operator or Technician level permissions running the system since they cannot typically start a protocol while a compiler error is present.

    Please add a tips on command before the second tips off task in the protocol in order to avoid the compiler error. It is possible to then skip this added tips on task using the task.skip() JavaScript command. The compiler does not take into account JavaScript when run, so it does not notice that tips on task will be skipped, avoiding this error and allowing any user level to run the protocol while still performing two consecutive tips off tasks.

    For Scripting User Guide Page References, please refer to these links:

    Using JaveScript in VWorks - Using JavaScript (agilent.com)

    Task Object (including task.skip()) - task object (agilent.com)

     

    Please share the version of VWorks and the head type being used with this Bravo if the behavior is different than what is described above. 

    It should not be required to perform a second tips off task and that is one reason that it flags in the compiler in the first place. The tips off command drives the W-axis to a specific position depending on the head type and that should flex the stripper plate and cause the tips to drop. This same physical action will happen when running a tips off task twice so depending on the circumstance this may not help fully remove these tips.

    Any residual tips being left behind usually is a sign of some other issue – such as the head’s W-axis not being homed properly, a damaged (or sticky) barrel, or static conditions causing the tips to cling. There are other ways to address these conditions besides implementing a second tips off task, depending on the root cause.

    We recommend attempting to contact to your local support resource listed on the contact us page of Agilent.com (Contact Us | Agilent) for additional assistance if this issue persists after attempting this protocol modification.

Reply
  • Thank you for reaching out with your Bravo question.

    The below suggestions are based on VWorks 14.2 when using a Bravo with a 96LT head, but we expect the behavior to be the same when running the system through other VWorks versions with either a 96LT, 96ST, and 384ST heads. 

    It is possible to have the tips off task occur twice in a row in VWorks. However, this will trigger a compiler error in the software stating that it is trying to perform tips off when there are no tips on the head.  An administrator level VWorks user could run the protocol despite these compiler errors and there are no physical issues that will occur as a result of this change so it would be possible to test this solution to see if it resolves the tips off problem.

    It may be necessary to work around the compiler errors if this modification resolves the error and will stay in place. Specifically, it will be necessary if there are users with Operator or Technician level permissions running the system since they cannot typically start a protocol while a compiler error is present.

    Please add a tips on command before the second tips off task in the protocol in order to avoid the compiler error. It is possible to then skip this added tips on task using the task.skip() JavaScript command. The compiler does not take into account JavaScript when run, so it does not notice that tips on task will be skipped, avoiding this error and allowing any user level to run the protocol while still performing two consecutive tips off tasks.

    For Scripting User Guide Page References, please refer to these links:

    Using JaveScript in VWorks - Using JavaScript (agilent.com)

    Task Object (including task.skip()) - task object (agilent.com)

     

    Please share the version of VWorks and the head type being used with this Bravo if the behavior is different than what is described above. 

    It should not be required to perform a second tips off task and that is one reason that it flags in the compiler in the first place. The tips off command drives the W-axis to a specific position depending on the head type and that should flex the stripper plate and cause the tips to drop. This same physical action will happen when running a tips off task twice so depending on the circumstance this may not help fully remove these tips.

    Any residual tips being left behind usually is a sign of some other issue – such as the head’s W-axis not being homed properly, a damaged (or sticky) barrel, or static conditions causing the tips to cling. There are other ways to address these conditions besides implementing a second tips off task, depending on the root cause.

    We recommend attempting to contact to your local support resource listed on the contact us page of Agilent.com (Contact Us | Agilent) for additional assistance if this issue persists after attempting this protocol modification.

Children
No Data
Was this helpful?