Hi all, hoping to get input from anyone who has run into something similar and figured out a fix or workaround.
I’ve been hitting frequent Method Editor crashes while developing in Venus 6. On one method I had ~6 crashes in about 4 hours of editing. The .med is around 28 MB. I’d had a similar issue earlier on a smaller method (~12 MB), while other methods I work with regularly (in the 20 to 115 MB range) have been stable.
The errors are inconsistent:
“An error occurred while running Vector. The error description is: Out of memory. (0x4 - 0x2 - 0x0)”
Checksum errors on save (most common): “Error opening file … for check sum verification. System error: An unknown error occurred while accessing [path]. (0x37 - 0x0 - 0x1)”
Sudden Method Editor crashes (closes down) with no dialog at all
Timing seems random: mid dialog edit, right after pressing OK in a dialog, or during regular edits in the main editor view. Recovery means rolling back to an older version and redoing the lost work, which is the painful part.
The methods don’t appear to be doing anything unusual in my opinion: no heavy use of images, dialogs aren’t too elaborate, no obviously heavy logic. Perhaps one element to flag is relatively heavy use of HSL blocks for logic: assignment values, maths, array operations…
What I’m hoping to learn from you all:
Whether anyone has tied this kind of crash pattern to a specific cause (file size threshold, dialog count, sync conflicts, HSL usage, etc.)
Whether there are logs or diagnostics worth capturing the next time it happens
Any practical workarounds that have helped you keep working through it
Not an expert here but a few things I might expect to consume a lot of memory are deck layouts with a lot of labware, submethods, and imported libraries.
No solution, just empathy. I also find that most of my crash-to-desktops happen when editing dialogues or right after committing changes to complicated logic. Maybe it’s some pre-validation issue.
It seems like the errors hide and wait in the shadows (probably next to the ctrl+z function) until I get really into the work setting up logic for labware states or fine tuning some user-facing dialogue. Suddenly the window is unresponsive and it’s already too late to save.
I never personally thought to look specifically for a pattern, I just set a timer on my phone to remind me to save every 10-15 minutes
Similar experience with dialogues, especially dialogues with multiple assets OR just dialogues with pictures. Some pictures feels like 50/50 risk of crashing…
There is also some bug/crashes when editing existent sequences where Venus gets stuck in a loop of throwing error messages.
When I worked in industrial automation and was using similarly-unreliable PLC programming environments, I had coworkers that had set up AutoHotkey scripts to press Ctrl+S every few minutes for the same reasons
That just jogged my memory about something, I’m wondering if its the same for you and others. The CTD (crash to desktop) seems more common when I end up copy/pasting the dialogues or some complicated block of script, like a loop, and then immediately access and edit that new section. Maybe its just a simple spike in resource utilization that leads to the subsequent crash?
You need to keep the pictures below 100mb, it actually warns you in red for custom dialogues if you’re over when designing the layout.
@Keltoum you should also check your custom dialogs as well, if you are using any, make the pictures below the threshold. Venus embeds the images in the method so this could be a culprit, though I’m not sure as when we had this error it’d crash mid run when using large images.
Thanks for sharing that, thanks for all the answers! The dialogs + pictures angle sounds pretty plausible in my case – I do have several dialogs with images, and a few of them are flagged in red, so there might be something there. Will keep an eye on whether crashes correlate with accessing those specifically.
I have recently been running into these issues as well. To try and reduce the chances of crashing randomly I started linking images in a custom dialog box to a file pathway so that way there is no need to save the an actual image within the custom dialog box. Secondly, I turned off the checksum validation in the system config editor. Since doing that venus 6 has only crashed on my once.
Hope that helps!
I also experienced regular crashes of the method editor with Venus 6. In my case it was the combination of long function & submethod library names combined with one of the two specific library views. The method editor crashed exactly when my curser moved over the long function name.
When using the tree view, the software doesn’t crash anymore.
Just a general heads up: Venus is in no way designed to create GUI-adjacent dialogs. I know the temptation of “If it is allowed it should be stable” is great, but I would always recommend to go either information-only (no pictures) or use a separate software for the GUI, which can be started from within Venus.
Though from personal experience I can only ever repeat that the maximum amount of times users in the lab will look at the fancy blinking pictures is two. They will quickly switch over to rote loading processes or simply stick a printed out picture of the full deck on the robot. Risking repeated crashes due to dialogues is rarely worth it.
Do you have any recommendations for software for the GUIs? I haven’t thought of this option before, but I bet there are some functionalities that maybe would be possible that aren’t supported in custom dialogs.
Just launch a .html chrome window via a batch file.
LLM’s have gotten so good it can generate you a static .html webpage that looks great in 2 seconds. Want to update the deck image? Just point the .html to a new jpeg. Custom dialogs are not useful anymore. Heck you can probably use 3js to make some crazy animations
If you want to get fancy, you can use fork join to wait for acknowledgment via dropping some sort of file in a directory. Need to drop variables between the two, some kinda of file, .csv is easy, but there is JSON and .xml libraries for Hamilton
I agree with the webpage approach, though I would always recommend programming the thing that organizes work with your precious samples yourself, rather than letting an LLM do that. Or at least to thoroughly vet the code.
As an addendum: Fork an join are quite powerful and having a GUI open that can influence your robot while it is running is absolutely the perfect application for these. However, every new parallel thread is going to make a system less stable and tying up loose ends in case of errors gets that much harder.
Yes, I have had the crashing issues with too many images and dialog boxes in Venus 6, my methods become unrecoverable. I have started generating pkg files fairly frequently so that I do not lose another method.
I am also not going to add as many images. I do reduce the size of each image down below the maximum. It’s interesting because I do not have this with Venus 4.
