Display current coordinates  

I'd focus on the cause of your crash...

Should be an issue that is solvable.  Is this a specific model that always crashes (sounds like it crashes on both printers).  Let's start there.  Is it a trash model that cannot possibly print?  (lots of them on thingiverse).

Model details

Yes it is just this specific model (which I designed, so hopefully it's not trash, haha!). The issue appears to happen at a certain height, around 117 mm if I remember correctly. I have been juggling troubleshooting with production of parts so I haven't checked everything I'd like to yet. This particular part is the only one out of my assembly that is that tall, so the other parts seem to be printing fine. I'm waiting for the "left" printer to finish so I can check if crash detection is on (it is off on the "right" printer).

One thing I did notice is that the top of the part is slightly outside of the footprint of the printer in the y-direction but the issue I'm seeing is in the x-direction. No errors have popped up about it and since it's in a different axis, we were thinking that's unrelated. I'll attach a screenshot of what I'm talking about.

Otherwise, same file, same material, same nozzle size (the right side is a knockoff but I doubt that is related...) on both printers. My colleague did a self-test on the "right" printer a couple days ago. It failed and he tightened the pulley, did a test again and it passed. We were hoping it was something small like that, but still seeing the issue. Yesterday I had a heckuva time trying to manually put the nozzle back in the correct position to finish the print.

Z-hop

Ok, the "left" printer has crash detection ON and the "right" printer has crash detection OFF. It shouldn't be crashing in the first place, so I wonder if adjusting the z-hop would help. The problem is, I don't know how to test it...I don't have a baseline measurement to compare against and I can't wait 16 hours to test. Any ideas?

@kdash

Could you save, zip, and upload a 3mf-file, it is way easier for someone to help?
And pics of the failed print(s).

Um, focus...

I'll let you muse about how to add nozzle movement to non-crash detecting bad prints ... I don't like turning off crash detection - when crashes happen, something caused it.  Whether it is blobbing falling onto the print from the nozzle (bad first layer Z can cause this, badly installed nozzle can do it too), or your part is warping on the bed (a number of issues, including bad design can cause this), if you hear a crash, you should focus on two things.  1 is does it repeat on the same printer.  You seem to be verifying it happens on both of your printers. 2. Is it the printer setup, or the model, or the sliced Gcode that need adjusting.

Logic here is - get rid of the crash and you don't have to invent new ways to work around core issues.

Since your model is crashing both printers (hard to tell, the story is getting long) it is a good bet that it's either the model itself, or warping.  With no pictures, there is no way to even guess.  Take some pictures of a crashed print - bottom layer, picture of your bed with the crash print removed (no fair cleaning it first), picture of the crashed layer from X and Y angle.  This will help people understand what you are dealing with.

If only one printer is crashing and your thing prints fine on the other printer (no shifted layers - perfect print - no work-arounds like turning off crash detection) - then it's more likely you have a hardware related issue to fix.  Bearing condition, rod condition, last time you stripped it down and packed the bearings, etc - and relevant pictures for a hardware investigation (such as a picture of the belt tension gauge installed on your X or Y belt - whichever one you think is the crash-dimension) ...

And in prusa slicer, slice your thing again, and then File/Save-as and then give that file a name.  Zip that file up and upload that compressed folder here using the choose file button below this white window when you are the one typing in it.

Focusing...

Thanks, Dan. My original post was intended just to ask how to find current coordinates as a TEMPORARY workaround. I can't find anything like that on the LCD screen on the printer itself or in OctoPrint as a plugin. The closest I found in OctoPrint is the Gcode Viewer, which is just pictorial. I'm not sure why crash detection was turned off on the "right" printer, and do plan to turn it back on after my current print.

I am a big proponent for "sharpening the axe" and not just applying bandaids to problems, but have a deadline on producing these parts and am trying to balance troubleshooting time with other aspects of my job. As they are not personal prints, I cannot share too much more information but appreciate you reaching out. I will continue to attack the issue in a systematic way. I am fairly confident it's not a first layer or warping issue (or if it is a warping issue, there's not much more I can do about it anyway). The challenge is finding quick ways to test so I don't have to wait 16 hours to realize I made another mistake. 

I keep seeing bearing issues popping up in relation to layer shifting, and do have to follow up with my colleague on that one. We probably are due for some routine maintenance but I don't think this is a hardware issue.

Layer shifts are always hardware setup issues

I'll just leave that there (post title).  If you are getting layer shifts, there is no software remedy.  I have some prints that always work - until they dont.  Just yesterday was printing another one (I sell them) and the print failed.  Then the next print failed.  Changed spools, and the next print failed - was layer shifting and ruining the part - on a two hour print.  Examined my X carriage bearing (left to right smoothness test) and sure enough, my X is binding slightly when it should be butter smooth.  Tomorrow I'll adjust X carriage tension - might be time for some new drylins on X for me.  

Model Change

Thanks Dan. After some review last week I made a design change to the model and the print seems to be working now. Long story short, I introduced flexibility into a feature that needed better support. The theory is that it was springing up and causing the nozzle to crash. Thanks very much for your time!