Green Button Go Best Practices

Wisdom of the crowd exercise.

Do you have GBG best practices?

If so, what’s something you wish knew when you started?


Biosero Apps dude here. I used GBG before I even started working at Biosero. One thing that I’ve learned real quick is that GBG is so flexible with its tools and everyone’s workflow is very nuanced that there is almost no best practices to follow by. That also means there’s a learning curve to using GBG. Everyone on my team has their own way to approach things and you learn what’s best by just trying things and breaking things fast. That being said…there are some approaches that may be better than others and it all depends on what your end-use case is. The tools are there for people to achieve what they want, but it all depends on how complicated people want to get. I highly recommend at least one person become a power user in the team. That means taking all the GBG courses up to advanced and even a developers course. It’s pretty much a requirement to know scripting in C# if you want to do all the super cool stuff.

Feel free to throw questions here if ya all need help. If I don’t have the answer, I can point you to someone who does.


One broad BP Id suggest is to keep your element lists clean. There are a lot of auto-generated elements, like variables, robot positions/sequences, procedures, etc. Auto-generation is extremely helpful, but is a two edged sword. You might end up with a bunch of auto-gen elements that you don’t use. Especially when the method gets larger and more complex, these add to clutter and confusion. Delete what you aren’t using, maintain consistent naming and you’ll save yourself some time and confusion.

From here, recommendations get more use case and device specific. One good example is the GBG Liquid Handling module. Best practice is to break LH methods into smaller functions and use the GBG LH module sequence logic to call them. You get better control and error handling in GBG.

Post up any specifics you need.


Full disclosure Biosero Account Manager here. For me, coming from a background in liquid handler centric automation. The best practice for me was changing the way I think about automation and designing system architecture around the software capabilities. It’s been a fun journey for me to think more about what my customers want to do, verses what we can do with what we have available.

As general practice in automation, I always revert to “Keep it simple…stupid”. It took me many years of experience to learn. Keeping it simple and supportable always seemed to be the best path to success. Just because we can does not mean you should.

Former Biosero Apps dude here. I have hard earned GBG best practices, especially around Fluent Control. Something I wish I’d known when I started: keep all the Fluent scripts in methods, and have them open before a run. Check the Readme for how to set up variables in FC so they can be controlled through GBG. Current versions of the driver will time out during long Fluent runs, you’ll need to implement a “keep alive” in the start loop to defeat this (although this is currently being worked on by Biosero, fingers crossed). If you want to see how I did this on a live system, pm me and I’ll walk you through it. Overall, beyond Fluent Control particulars, I wish I knew when I started that GBG is great for what it was built for: reader-peeler workcells without liquid handlers. On simple systems, it just works and is quite intuitive. Once you get into a workcell with a liquid handler that is not Hamilton of the right vintage, it becomes a game of hacking through social connections to support staff and Biosero’s documentation and personal sheer unwillingness to quit. As the world exists right now, I still don’t see a better alternative.


Have them open before a run?

Could you elaborate a bit?