Why is my extruder making weird calliope noises?

[626Pilot]

I printed the snowman example that came on the SD card, and that worked fine. However, when I use KISSlicer to slice something - and I tried two separate files - the printer slows down almost to nothing when it goes around a corner, and the extruder makes what I can only describe as bizarre, musical noises. Most of the weird sounds are after 0:40.

[youtube]http://www.youtube.com/watch?v=rt__MDB10Vc[/youtube]

[bot]

That definitely is very odd. Can you post the gcode file?

[Jimustanguitar]

I'd call that a solo more than a duet.

(sorry, somebody had to do it)

[mhackney]

Odd that your experience has been almost opposite mine. My Duet v.6 and v.8.5 worked out of the box. I generate KISS gcode and it is smooth and fast - no corner slowdown like that and no funny sounding stepper. Only running 1 extruder on the .8.5 right now but going to be working on dual with a Cyclops in the next couple of weeks.

[bot]

I had the same thing happen to me after switching on extruder elasticity compensation. M572 P3 S0.06. Set it to zero and make sure it's not in any config files. It might have to do with a negative extruder move at the beginning of the file, combined with extruder elasticity blabla.

[626Pilot]

It's in the way the extruder "position" is reckoned. This is my file, that doesn't print right, and - as I have just observed - involves the extruder spinning at ludicrous speed, chewing up the plastic. That's where the calliope noises are coming from. It's being told to spin INCREDIBLY fast.

Code: Select all

; 'Prime Pillar Path', 3.4 [feed mm/s], 35.0 [head mm/s]
G1 X-23.29 Y19.8 Z0.6 E0 F12000
G1 X-23.29 Y19.8 Z0.35 E0 F6000
G1 E2.5 F1500
G1 X-23.29 Y-19.98 E6.3384 F2100
G1 X-22.96 Y-21.39 E6.4773
G1 X-21.93 Y-22.62 E6.6325
G1 X-20.43 Y-23.25 E6.7895
G1 X-19.8 Y-23.29 E6.8503
G1 X19.98 Y-23.29 E10.6887
G1 X21.39 Y-22.96 E10.8277
G1 X22.62 Y-21.93 E10.9828
G1 X23.25 Y-20.43 E11.1398
G1 X23.29 Y-19.8 E11.2006
G1 X23.29 Y19.98 E15.039
G1 X22.96 Y21.39 E15.178
G1 X21.93 Y22.62 E15.3331
G1 X20.43 Y23.25 E15.4902
G1 X19.8 Y23.29 E15.551
G1 X-19.98 Y23.29 E19.3894
G1 X-21.37 Y22.96 E19.5267
G1 X-22.51 Y22.03 E19.6688
G1 X-23.05 Y21.13 E19.7699
G1 X-23.29 Y19.8 E19.9003

See how the E commands are always increasing, sometimes by several millimeters at once? It's using absolute extruder positions. The firmware thinks it's being asked to advance the extruder 5mm at a time, 10mm at a time, etc., when what the slicer is really asking for is fractions of a millimeter at a time.

This is from Snowman.g, which prints correctly:

Code: Select all

G21 ; set units to millimeters
G90 ; use absolute coordinates
M83 ; use relative distances for extrusion
G1 E-3.50000 F2400.00000
G1 Z0.300 F12000.000
G1 X53.661 Y48.317 F12000.000
G1 E3.50000 F2400.00000
G1 X55.530 Y46.241 E0.25623 F1200.000
G1 X56.110 Y45.719 E0.07166
G1 X58.647 Y43.875 E0.28772
G1 X59.324 Y43.485 E0.07166
G1 X62.189 Y42.210 E0.28772
G1 X62.931 Y41.968 E0.07164
G1 X65.999 Y41.316 E0.28772
G1 X66.761 Y41.235 E0.07036
G1 X90.343 Y41.152 E2.16369

These E-commands are relative. The controller was assuming that I wanted relative commands.

I solved the problem by adding M82 (set extruder to absolute positioning) to my G-code startup. G90 (which does the same thing) was already there, but for whatever reason it doesn't work.

[IMBoring25]

Even though the description says ALL coordinates, I was under the impression G90/G91 affect only the X, Y, and Z axes.

[Xenocrates]

G90/G91 are from industrial CNC machines, which don't exactly have extruders. So they affect all the axis's. But the Extruder isn't exactly an axis. Nor is it a co-ordinate system. The closest I can think of is spindle speed. It's a tooling parameter, rather than a machine parameter really. So there is some logic to G90 and 91 not doing what was expected there. It would be frustrating as hell, and I think it's rather stupid for a slicer to not output all the various flag commands to set the machine state to make what it's outputting work. It would be like if you forgot to turn tool length offsets on. There's no way it can hurt you to check, and it will cause issues if you don't do it. Why is G01 on every line? It should be modal until G00 or G02/03/13/11 toggle it to another positioning system? Why are so many of the commands on their own lines? Unless they are in the same family it shouldn't change anything to put them together. Why put the comments after semi-colons, rather than in parenthesis? Semi-colons are what I'm used to as a EOB character, and it would eliminate the idiocy of various different returns parsing differently.

[Grumbles about silly reprap G conventions]

I guess I kinda have to give them a pass on that, considering that I doubt most people would have had much exposure to industrial strains of G, but seriously, the documentation on a lot of the G seems terrible, and they don't really explain things well. A lot of useful stuff isn't well implemented, and even more of it is not used by the slicers. I mean, if say M98 was in there, or better yet, M97, then you could drastically reduce the size of a program, as each identical layer set would only be paramaterized once, and you would just increment the Z before calling the sub-routine again. I hate that I know all these brilliant tricks in G, and yet the machines I have of my own to play with don't support them, and never will. And I can't exactly fix that, because I don't know a thing about writing code beyond G, V+, VAL, and some basic SQL. And Brainfuck, but that's a toy language.

Some of this stuff would actually make sense, in isolation. But with prior exposure to the G used by Haas machines, among others, I guess it's like how 626 views Repetier after being exposed to Smoothieware. It works, but it's endlessly frustrating, knowing something so much better exists, but we can't use it because the hardware is incompatible. Fortunately for us all, we don't have to work with alphabetical keyboards. So I guess that's a plus side to it not being an industrial machine.

[ZakRabbit]

G90/G91 are from industrial CNC machines, which don't exactly have extruders. So they affect all the axis's. But the Extruder isn't exactly an axis. Nor is it a co-ordinate system. The closest I can think of is spindle speed. It's a tooling parameter, rather than a machine parameter really. So there is some logic to G90 and 91 not doing what was expected there. It would be frustrating as hell, and I think it's rather stupid for a slicer to not output all the various flag commands to set the machine state to make what it's outputting work. It would be like if you forgot to turn tool length offsets on. There's no way it can hurt you to check, and it will cause issues if you don't do it. Why is G01 on every line? It should be modal until G00 or G02/03/13/11 toggle it to another positioning system? Why are so many of the commands on their own lines? Unless they are in the same family it shouldn't change anything to put them together. Why put the comments after semi-colons, rather than in parenthesis? Semi-colons are what I'm used to as a EOB character, and it would eliminate the idiocy of various different returns parsing differently.

[Grumbles about silly reprap G conventions]

I guess I kinda have to give them a pass on that, considering that I doubt most people would have had much exposure to industrial strains of G, but seriously, the documentation on a lot of the G seems terrible, and they don't really explain things well. A lot of useful stuff isn't well implemented, and even more of it is not used by the slicers. I mean, if say M98 was in there, or better yet, M97, then you could drastically reduce the size of a program, as each identical layer set would only be paramaterized once, and you would just increment the Z before calling the sub-routine again. I hate that I know all these brilliant tricks in G, and yet the machines I have of my own to play with don't support them, and never will. And I can't exactly fix that, because I don't know a thing about writing code beyond G, V+, VAL, and some basic SQL. And Brainfuck, but that's a toy language.

Some of this stuff would actually make sense, in isolation. But with prior exposure to the G used by Haas machines, among others, I guess it's like how 626 views Repetier after being exposed to Smoothieware. It works, but it's endlessly frustrating, knowing something so much better exists, but we can't use it because the hardware is incompatible. Fortunately for us all, we don't have to work with alphabetical keyboards. So I guess that's a plus side to it not being an industrial machine.

As a Haas guy, I have a hard time too. Like you said, simply being able to use G2 or G3 would make the code so much shorter, but I guess we're not there yet. I doubt it'll be long though.

[626Pilot]

G-code is decades old, full of magic numbers that work differently on different controllers. Firmware developers are out there right now, picking random codes and assigning arbitrary functions to them (and I should know, because I'm one of them). I'm sure someday it'll be replaced with something that doesn't use magic numbers, or other weird conventions.

I think the extruder is a coordinate system, one-dimensional.