Wisdom of the crowd exercise.
Do you have GBG best practices?
If so, what’s something you wish knew when you started?
5 Likes
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.
2 Likes
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.
1 Like
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.
1 Like
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.
2 Likes
Have them open before a run?
Could you elaborate a bit?
Hey man, I’m the solutions architect over at Biosero, just takin’ it easy, you know?
So, here’s a little wisdom I can lay on ya, dude:
Alright, so check this out, man: When you’re setting up your system’s layout and naming your gadgets, always think about making room for the future, you know?
Like, if you’ve got just one dispenser now, call it Dispenser_1. That way, if the universe smiles on you and you end up needing another, you just slide in Dispenser_2. No fuss, no muss. 'Cause, dude, all your scripts and whatnot use these names, and it’s a real bummer to have to go back and rename everything. Keeps it all copacetic.
And another thing, man, don’t let anyone in this thread harsh your mellow. Just keep your mind limber and roll with the punches. The Dude abides, and so should you, man.
4 Likes
That’s great, C# is an amazing language. .NET 8 and C# are freaking amazing but from my understanding, GBG uses .NET Framework 4.8 so you don’t get some of the latest & coolest tools.
Have you found modern C# .DLL references in scripts to be a challenge?
Great advice, (maybe) luckily with my first job I was thrown into the deep end so I learned this early! Cheers!
1 Like
…it becomes a game of hacking through social connections to support staff and Biosero’s documentation and personal sheer unwillingness to quit.
Absolutely, it takes a village and I firmly believe it.
1 Like
That’s great advice. Also ideally I’d like to never interface with GUI software and build everything dynamically so I have total control. Ping me in a year.
2 Likes
I found I haven’t really needed to rely on the modern stuff at all. 99% of the stuff we need to do can be achieved using 4.8. I did run into a case where some escape variable wasn’t working and was told it was too “new” to work, so I had to work around it syntactically so NBD for me.
I will premise that I am not a software engineer by training, so my programming skills are good enough at best. I’m getting better though! We really enjoy people like you that try and “break” GBG with the latest stuff. It keeps us on our toes. Going to be fun to see what users come up with especially with all these new AI/ML tools becoming more and more mainstream.
2 Likes
Yeah that’s definitely true with 4.8, but it can just be achieved with less lines of code in newer versions 
Very true. I will throw out a few more GBG best practices though:
Best practice #542671…Format your code so its readable, well commented, and in case of your timely demise…someone knows wtf you wrote without going cross eyed.
#542672, try not to write a script that is hardcoded for one particular step. If its used or can be used in multiple spots, parameterize the script so its easily usable elsewhere allowing it to be scalable and sharable.
#542673…if you can achieve the same thing without scripts…favor that instead.
#542674…don’t forget to also leave comments on custom procedures your creating. I use the note function to add comments so that whoever goes digging in the advanced tab knows what a particular procedure does.
And as always…back up stuff up regularly.
2 Likes
These are all great best practices for any code base, not just GBG.
Thanks for sharing!
1 Like