Printing over serial, UM2 does not respect end stop switches/limits?

[twistx 0]

Unlike my original ultimaker which had switches to prevent these collisions, my UM2 seems to happily run past the end limits and ignore switch states when an erroneous command is given over usb.

This has resulted in the bed running into the print head on a couple of occasions. And when the bed is already homed it will still attempt to lower the bed further despite the switch already being activated. Same with the furthest location from home on the x and y axis, it will continue to try moving past its known limit if given that command.

So what is needed to prevent this from happening, besides abandoning the printing over usb method that I've been enjoying? Buy and install more end-stops? Changes in the Arduino firmware? I've been extremely careful since I noticed this, but I'd rather be have assurance knowing the machine won't just destroy itself. It seems my bed is already slightly bent.

 

[twistx 0]

Just to clarify, topic should say Printing over USB, but this issue happens when I input manual commands not when printing but I imagine that would be possible with some bad settings in your slicer. I'm using Cura again now, was using Slic3r but gave up on that. I'm also using Octoprint to monitor prints remotely from another room, which is also how I'm issuing manual commands.

 

[illuminarti 18]

If you are printing over USB, then you need to make sure that Cura is set to generate normal gcode, not Ultigcode - as the latter assumes that the printer will do various start-up tasks like heating and homing the bed which don't happen when printing over USB. You also need to make sure that the start gcode sequence correctly homes all of the axes before the print starts; until they have been homed, the printer has no idea where the head is located.

On the Ultimaker², the only limit switches are located at the back left corner for x & y, and the bottom of the printer for z. Running the bed leveling wizard is essential to being able to know the correct z=0 position, as is the initial z-homing.

There is a bug in the firmware at present, which will cause the bed to raise at the start of a USB/non-ultigcode print even though the bed may not have been homed yet so the printer is unsure of its true z position. Therefore, it would be best to run the 'lower bed' command from the Maintenance -> Advanced menu before starting any prints, so that the z-axis position is calibrated.

 

[twistx 0]

Yep, using normal gcode in Cura. Its not the actual printing process that this happens with. Its when I issue commands to the printer manually with Octoprint. From what you're saying I need to always home before moving any of the axis? I will test that tomorrow.

But what is with the bed wanting to continue lowering when it is already in the home position if I issue another lower command? Does the software not see the switch state but only the transition?

Even if the machine knows its position in software after homing, why would ultimaker choose to omit these switches that the original had to prevent this? There seems to be plenty of opportunity for collisions and at almost twice the cost of the original I expected to see more not less.

Do you happen to know if the control board has the ability to take extra switches? I haven't examined the board yet. If possible I would at least install a top Z switch to prevent my bed from getting any more messed up.

 

[Daid 306]

https://github.com/Ultimaker/Ultimaker2Marlin/blob/master/Marlin/Configuration_adv.h#L91

 

[gr5 2,168]

Daid who posted above wrote Cura and also modified Marlin quite a bit to get it to work for the UM2. He is pointing out a flag that tells Marlin to ignore the limit switches for anything other than homing. You can comment that out and rebuild Marlin if you want.

Marlin has software endstops. Once you've homed the 3 axes you should be fine.

Also the UM Original and UM2 are very tough - you are unlikely to damage your machine by going beyond any of the endstops. I think every UM Original and UM2 has gone beyond a few endstops within a year of use. Mine certainly both have.

 

[twistx 0]

Thank you for the responses.

Daid, I appreciate you pointing out that flag. I'll rebuild marlin with that commented out.

I have no doubt that these machines are tough, I put my original through all sorts of punishment, but I never underestimate my ability to break something.

I discovered last night when calibrating the bed after the last collision that the home corner was .3mm lower than the rest of the bed. I took the bed off this morning and with a square I could see its definitely not flat. I didn't check this when I first received the machine but I imagine it wasn't like this before. There's no pressure on the square so the deflection looks a bit worse than it is when secured to the Z plate.

 

[twistx 0]

So I rebuilt the bed and ran a few test prints, just a hollow square 5mm wide and 1mm tall around the perimeter of the bed and the back side is still off by a few tenths of a mm. Doesn't really make sense to me since the glass is perfectly flat and the clips on the corners should pull the bed to the glass, so I took the back spring out and noticed it is curved. I turned it and put it back so it curves along the Y axis not the X and that seems to have reduced the difference to about .1mm along the back. Printing a few more times for calibration, but I might slightly adjust that spring again. I think that is the origin of my problems though.

 

[twistx 0]

I've got the back end to 5-10/100ths within eachother. Leaving it there because I don't think I can improve it any further.

Went on to printing the test cylinder because the first time I tried it didn't work, now I've installed Roberts extruder assembly and tried it again and still the same result. 3 and 4mm/s are poor, and at 5mm/s it either chews up the filament or the stepper just starts skipping depending on the spring tension.

I'll move to the other discussion for those tests.