robinmdh

I meant on the printer. use developer mode to ssh into the printer and edit the file there using the vi command or use winscp to edit the file with windows. This will save you from editing and compiling marlin at least. Please note that a microstep in the S5 is half the size as that of the UM3 so the printer should have a higher resolution, so if you're not getting that resolution, before doing anything I'd check the tension in the belts, that might be the problem instead. good luck!

you can set the steps per unit in the machine configuration file for both the UM3 and S5 located in /usr/share/griffin/griffin/machines/ have a look at 9051.json and um3.json

The marlin code is available or can be made available upon request. the python code you can read on the printer. and hey the flow sensor for the S5 was originally planned for the UM3, actually the feeder design including flow sensor can be mounted and connected to the UM3. There is also already code to report a flow sensor error causing the printer to pause.

I think the only advantage for your prints that the S5 has is filament flow sensor and multi point bed leveling, which seriously increases buildplate adhesion, though I still recommend using (uhu or pritt) glue on a hot buildplate spread out with a wet sponge for PLA. The S5 has a heavier print head and thus accelerates slightly slower. there is lower throughput that affects surface quality in extremely highly detailed models in the UM3 which we've improved in the S5 and not yet ported to the UM3, don't worry though it's not bad and we will port it to the UM3. There is also future add-ons to consider, as Sander said: So you can count on some accessories/add-ons that will require that hardware.l

It depends on what you want. Do you want an guranteed working Marlin for UMO take the version of Ultimaker. If you don't mind some testing and trial and Error the mainline marlin can be made to work on the UMO. I'd probably just try to merge the changes UM made to the config.h into the marlin mainline's version and build and see if it works first.

can't you just build with arduino? it's only slightly more complex.

I'll add it to the board, since we can actually see if the previous material was different than the current material we could do this automatically when needed. The question then becomes should we only do this for a material type change or for a color change as well (keeping in mind that if you don't use use material identified by RFID this won't work)? OR just add a flush material option to the print-core or material menu to allow the user to do so manually after changing cores?

I hope you don't mind if I nitpick a little bit, what you describe here is EMC. ESD happens when you're wearing your fleece jacket in the winter and you moving and walking around generates a charge via tribocharging . When that buildup charge suddenly discharges, that is a great example of an ESD event.

@Fulv I'd use the BB core for woodfill if you use the Ultimaker cores, that will cause a bit more oozing but less chance for plugs when printing with 0.4mm cores that is, I'm not sure if this matters for larger diameter cores. the BB core geometry vs AA core can be sumarised as: AA \ \_ _/ / \__| |_/ BB \ \ / / \_| |_/ Not having the flat bit helps pushing the bits of wood through.

TL;DR -> @chrisgr99 If the model was to high poly for Meshlab then I guess that was it and the screen is unrelated. Don't worry too much about the screen, if it goes back to normal after a minute or so then everything is fine. You can be a great source of ESD event yourself, just FYI, your clothes etc can generate charges well over 5000Volts just with very few joules of energy. The sudden discharge of that can still break and disrupt electronics, as we have seen with the screen which is why it resets it's synchronization once in a while. This this is more likely in dry environments as moisture causes some random lower resistance pathways for those charges to safely dissipate trough. And a resounding NO on the overflow thing, it just doesn't work that way. It might make the screen update slower but not nothing else as these parts are separate programs.

I've seen all kinds of shifts happen on the display, it is usually caused by a powerfull Electro static distcharge(ESD) but it can also be caused by constant EMC. The fact that it happens every time is strongly indicative of nearby electrical disturbances, could be a microwave or anything that generates sparks, broken CLF tubes, that kind of stuff. That same disturbance is also wreaking havoc on the communication channel between the real time controller(marlin/arduino) and the high level controller (griffin/olimex/linux) this lowers the potential throughput a lot, throughput required when printing more high-poly models but your EMC disturbance could make it problematic for even simple medium poly prints. This can most likely not be fixed by firmware only more shielding. And any other 3d printers in that environment would quite possibly skip moves (not stop though, as most don't have error recovery on their read from serial or SD card). I suggest moving the printer to a different room or building and seeing if the problem persists. P.S: (the display would likely shift left to right or top to bottom and then wrap around so that the edges of the screen are now in the middle, not rotated).

you'll need to build from mainline marlin the grid based leveling was never merged in and the new S5 does it before the data goes to marlin. have a look here: https://github.com/MarlinFirmware/Marlin You might need to take configure quite a few settings for it to work on your UMO though, if you don't know what you're doing I would recommend getting help from someone that does. From what I remember looking at the code I remember there were some inconsistencies which is why we didn't use it.

I'm not exactly sure, however I remember a mechanical engeneer telling me the bit with the cooling ribs should not become much hotter then 90 degc this is a very safe conservative estimate if I recall but keeping the Teflon insert from degrading is important so if you can monitor that and/or add cooling if needed it would likely help keep your printcore functional. For the rest of the printcore: The metal themselves should not have a problem with a heatgun but the sensor and heater cartridge might and I don't know.

@geert_2: from memory -> It's in the order of 100 microns on some points of the buildplate, on some locations it's below 10 microns, there appears to be a quick and a slow action to the point that the build platform below the bed is likely a big contributing factor. There is more change at the front of the printer then at the back in some cases. So not as much just the glass that that does do something but consider the whole printer. It's also not really about being at a specific offset at a specific temperature but rather a warping of the buildplate during the warming up, because this does not happen evenly in the whole buildplate. I don't see much deformation after the buildplate has reached temperature and been there for a little while.

Often there is a little blob/bit of plastic still stuck to the nozzle, that can effect the measurements but it's also slowly squished and pushed out of the way by repeated probes. This can e quite frustrating, but cleaning the nozzles before a print can be a huge help. (or after a print, but then let the cooldown happen at the end as this prevents oozing at the start of the next)

@geert_2 the glass plate warps quite a bit while heating up, so we're changing to starting measuring after the heat up is done, it still moves a little bit afterwards but that is less. I don't know if the movement of the glass has any effect on warping but indirectly it has an effect on buildplate adhesion since you're laying down your first layer with a slightly incorrect layer height. The slow deformation over time should not cause any issues with multi-point leveling either, that movement is far slower and so far we level every print. If you're interested I do have measurement data or a script to do active leveling probes while the buildplate is heating up and cooling down for/from the UM3, if you do this often enough you can get an idea of the general movements involved. we did make a movie of this somewhere, I'll see if we can find/post that if there's interest.

indeed, including enter, I've tested this and it works but you can also set te temperature property. in the debug shell you get by loggin in as ultimaker: select printer printer/head/0/slot/0 set pre_tune_target_temperature 200 and since you asked to see the temperature you can also either enter the list command or the get current_temperature command to see the temperature instead of looking at the screen. the same properties exist for the bed and both hotends, type select <tab><tab> to get an idea of how to set the properties of those sub-systems

How sure are you guys that this isn't just a windows caching of the zeroconf network discovery? If so just delete the network adapter in the device manager and scan for "new" hardware to install it again and it'll work after that. Windows...

this works fine as long as it's directly after eachother, for instance if you paste: sendgcode M145 T0 sendgcode M104 S200 into the (cmd) shell After a millisecond it is turned back off. Since the temp is 0 and the target is 0... I think this was done to avoid the hotend error uppo removal of the hotend as much as possible.

While not too bad an idea, what happens then if you insert a new hotend cartridge and the printer fails active leveling? The level is stored per hotend cartridge/position so that info would be gone at that point. The detection range also isn't infinite, we have to start somewhere that doesn't make it take too long for everyone. On the good side we've improved this a lot recently both speed and accuracy but I have no idea when those changes will come to the UM3

on ancient firmware this was an option, but too often people edited the existing materials in cura which was then synced to the printer and consequently ruined printing for everyone else on that printer. We realized we'd need a better way to deal with this, that and the tiny screen where it is difficult to show an endless list of materials makes this tricky. In practice just make your material a copy of an existing generic material in Cura, select the material you've copied from on the printer and you'll be fine!

this is one of the reasons why the bigger S5 has multi-point active leveling, it really makes a lot of difference. Those anodized aluminum build plates for the S5 turn out to be even harder to get flat ? With glass buildplate suppliers some batches of build plates we had have been outside of specifications for sure! I'd still prefer the safe tempered glass to the flatter standard glass IMHO.

I think during manual leveling the total distance between the top and bottom of the buildplate has gone outside of specifications (there is an end to what we compensate for) Can you: Make sure that your buildplate bottom and top are approximately 14mm apart. Then manual level again. Then try again.

This does not matter/USB would slightly more limiting. The issue is likely with the high poly count of your model, which generates very short segments of gcode? In a way all printers will have problems with this at some resolutions which is why a lot of firmwares discards too small moves and slicers have some limits, but short bursts of high detail are still very possible. If so we're actually working on improving this but it's not a simple solution, bandwidth is arguably a finite resource in a system like this and it's made worse by EMC interference which is not the same for all users, so it'll take a while yet. You could test with different firmware versions as we have been making changes to the communication protocol. perhaps V3.6.x is a good point to start in that case.

why not just measure the filament before the deformation has occurred? and how much the feeder moves the fillament was alwais a calibrated value and varies between materials a bit due to how much the feeder wheel digs into the material. you could compensate for that but you might need more information about why under extrusion is happening... perhaps material profiles including calibration data for actual e steps?