Ham
December 31, 2025, 8:03pm
1
Hello,
Today, we had a Hamilton Star serviced for an unrelated reason (Core head crashed due to being thrown too far in x during a run, gantry rail was lubricated and adjustments were performed) and now I’m trying to perform testing to determine if the original issue has been resolved or not.
The other instruments with this same script are not having this issue, so I want to try to identify why this is happening to see if we can resolve it ourselves or if we need the FSE to intervene for this new issue.
Despite us having run this script in its entirety with this step as-is for years, it is suddenly “skipping” over the unload step for each carrier near the beginning of the script. As you can see in the log file, it is acknowledging that the unload step should be happening, but the Autoloader doesn’t respond to any of the requests and within 1 second the script continues on. Then, when it’s time for the carriers to be loaded back on the instrument (according to the order of the script), the Autoloader does move and try to line up to load a carrier back on deck.
The instrument can perform Weekly Maintenance without any issue, and the issue is replicable after a full power cycle and reinitialization.
Happy to provide any more information to try to get a better grasp on what could be causing this.
Thank you in advance and happy New Years Eve!
Hello @Ham
Would you be able to upload the communication trace from today? I need to review the responses from firmware to see what’s going on and why errors aren’t being thrown.
This file will be in the default LogFiles folder with the following prefix:
HxUsbComm(todays date).trc
Thanks.
-Nick
Something that can happen during FSE interventions is that x, y, z coordinates change slightly. A classic problem that can occur then is that loading steps no longer work, as tracks are calculated via x coordinates and even if you’re just 0.1 mm in the neighboring track’s space, it will start looking for the carrier one track to the left or right. If your unloading steps have errorhandling that ignores missing carriers, it would look like you are skiping unloading the respective tracks. I would recommend writing a short test method that unloads a carrier on, say, track 10, but insert carriers on tracks 9, 10 and 11. Then you can check which carrier gets unloaded and see whether this is the problem you are facing. If it is, you don’t have to reteach everything, just call in the FSE again to repeat the deck adjustment macros more carefully.
Check the rear of the carrier and see if its damaged. Sometimes the metal piece is missing or damaged. Or see if the carrier isn’t push all the way into the deck it won’t be detected as present by the Hamilton. This causes the autoloader to think that there is no carrier loaded even if it is present on the deck.
Ham
January 2, 2026, 1:25pm
5
Yes! It’s not letting me attach the file itself to this thread since it’s not a photo, but below I’ve pasted the immediate information before, during, and after the time period of the attempted unloading per the screenshot in my initial post (14:37:52). Thank you.
< 14:37:32.479 8AF#8000#00: C0RQid0101
14:37:32.495 8AF#8000#00: C0RQid0101rq0000
Ham
January 2, 2026, 1:27pm
6
Thank you for the info, that’s good to keep in mind. In our case, based on the log file it seems like the script is auto ‘continuing’ through whatever error it’s possibly encountering in the background, however the unload step’s error handling is all default settings, none of which are continue. Execution error handling is set to repeat by default but it’s not attempting to repeat at all.
Ham
January 2, 2026, 1:28pm
7
Thank you, we checked that first but that is good information to include for others who may encounter unloading issues!
Roooo
January 4, 2026, 7:15am
8
I don’t see firmware errors during the unloading timeframe.
The carrier sensors are checked 5 times and always return:
C0RCid0237er00/00cd10400002082082ce00000000000010400002082082
I think you’re supposed to convert the return value from hex to binary to figure out which tracks it detects carriers on which yields
00010000010000000000000000000010000010000010000010000010
corresponding to tracks 2, 8, 14, 20, 26, 47, 53
There are also multiple commands to turn on the cover lightsC0CPid0224cl00000000000007cb00000000000007C0CPid0227cl000000000001F8cb000000000001F8C0CPid0230cl00000000007E00cb00000000007E00C0CPid0233cl000000001F8000cb000000001F8000C0CPid0236cl00000007E00000cb00000007E00000
converting those from hex to binary yields:
111
111111000
111111000000000
111111000000000000000
111111000000000000000000000
Tracks 1-3, 4-9, 10-15, 16-21, 22-27
Not sure what the expected track numbers your carriers are in, but as a previous poster mentioned, worth trying with your carriers shifted over a track. Hopefully a Hamilton forum member will correct if I’ve misinterpreted how to read these firmware responses.
1 Like
Ham
January 5, 2026, 1:49pm
9
Thank you for the insight! I did try shifting over a track but unfortunately the same behavior persisted. The FSE will be here today, so hopefully the issue will be resolved.
1 Like
