RRF 3.1.1 M572 breaks M591

dc42 · 14 Jul 2020, 07:45

@gnydick said in RRF 3.1.1 M572 breaks M591:

Is it possible to record the PA induced movements and send them to a file or console or something? I have to imagine that part of your development must include the ability to debug what's actually happening?

It's possible to get a record of all movements by enabling both Move and DDA debugging using M111. This causes all DDAs to be output to USB. You can tell if PA reverses the movement because if it does, reverseStartStep in the extruder DDA will be less than totalSteps. However, sending so much data to USB will slow the print down when there are short segments.

gnydick · 5 Aug 2020, 20:21

@dc42 that's cool, I don't mind if it slows down. How do I safely connect to usb without creating a ground loop?

A Former User · 14 Jul 2020, 23:34

could try asking google?
https://www.google.com/search?q=duet+ground+loop

tl;dr get an usb isolator

gnydick · 14 Jul 2020, 23:35

@dc42 I can also change my sensor to be much lower resolution, btw

gnydick · 5 Aug 2020, 20:21

@dc42 bump, USB ground loop?

Phaedrux · 5 Aug 2020, 21:36

To avoid a ground loop use a laptop running on battery or if using a PC ensure you're on the same outlet as the printer.

Or get a USB isolator.

More info here: https://duet3d.dozuki.com/Wiki/USB_ground_loops

gnydick · 8 Aug 2020, 04:56

@Phaedrux thanks!

gnydick · 8 Aug 2020, 04:59

It seems like this is a common issue. Why is that? And why is it that things like USB peripherals for computers that have their own power supply don't suffer from this?

dc42 · 8 Aug 2020, 21:17

@gnydick said in RRF 3.1.1 M572 breaks M591:

It seems like this is a common issue. Why is that?

Because electrical wiring in some places is crap. I use USB for debugging frequently. I never have an issue with ground loops; but I live in a modern building, wired to UK electrical standards (which are amongst the best in the world), and all the sockets in my office are on the same ring main.

And why is it that things like USB peripherals for computers that have their own power supply don't suffer from this?

They typically either use a double-insulated PSU, or the entire device is encased in plastic so that no connection is needed between the PSU output and ground. Some may possibly include a USB isolator.

If Duets were commonly used with USB connections, then we would include a USB isolator on board. But Duets are rarely controlled via USB, so the extra £10 to £15 retail cost would be a waste for the vast majority of users - and there would be the disadvantage that you would not be able to use USB power alone during commissioning.

gnydick · 15 Aug 2020, 03:49

Thanks for the explanation, @dc42 .

It's becoming obvious that a simple pulsing sensor will never work as implemented.

I've tried more space between windows on the encoder, larger windows on the encoder.

No matter what, an edge is found every once in a while and travels back and forth through the light beam, throwing it WAAAAY off.

I believe at this point the logic needs to be fixed in 2 ways.

The pulse/mm %-age should be flipped to mm/pulse. The mismatch in numbers is extremely misleading. The below example shows the disconnect.

Pulse-type filament monitor on pin e0stop, enabled, sensitivity 20.000mm/pulse, allowed movement 50% to 300%, check every 25.0mm, measured sensitivity 38.053mm/pulse, measured minimum 40%, maximum 77% over 76.1mm

If you're going to support a pulsing sensor, honestly, it should work. I recommend either deprecating it or fixing it. It should know to ignore synthetic extrusion/retraction movements induced by the duet itself from pressure advance or anything else. I.e. it should only track pulses for movements from the gcode. I understand that PA creates more movements, but the fact that the firmware injects those movements means it can distinguish between original and injected.

gnydick · 15 Aug 2020, 05:09

Also, there's something wrong with the tracking.

The console output is not incrementing. This happens a lot.

console (2).txt

gnydick · 6 Sept 2020, 05:21

@dc42 Can you please give some guidance here? I described many problems with using a pulsing filament sensor, but you've yet to give an example of a hardware configuration that will actually work, since it seems like pressure advance is going to break it no matter what.

dc42 · 6 Sept 2020, 09:33

I don't know of a hardware configuration that will work. I only added support for pulsing filament sensors because some users asked for it. My guess is that if you specify a long enough comparison distance, it will work reasonable well, but you will have to extend the upper range of allowed measurement to handle the case of backwards motion. For example, instead of allowing 70% to 130% movement, maybe you would need to allow 70% to 180%.

The code attempts to ignore extruder-only movement by default, so that retracts and reprimes are not counted. This should make it ignore the majority of pulses received due to backwards movement, although not backward movements at the end of printing moves when high pressure advance is used. Feel free to review the code, it's possible that it's buggy.

gnydick · 7 Sept 2020, 08:56

@dc42 it's the PA movements that send it way over the top. Can you fix that so it knows how to deal with those?

dc42 · 7 Sept 2020, 16:43

How much PA are you using?

gnydick · 9 Jul 2020, 23:36

@dc42 0.09, but it's also the other things I was mentioning, like the dial jogging back and forth during short extrusions and retractions in high detail areas. All sorts of weird motion corner cases where the edge of the window in the encoder just happens to end up right on the edge of the sensor, so it wags back and forth.

gnydick · 29 Sept 2020, 07:07

@dc42 If the PA is not taken into account for pulsing sensor, is it taken into for the more precise sensor types that can detect retract v. exrude?

gnydick · 29 Sept 2020, 08:06

there was well over 100mm of extrusion

1:03:06 AMM591 D1
Pulse-type filament monitor on pin e1stop, enabled, sensitivity 10.000mm/pulse, allowed movement 80% to 120%, check every 15.0mm, no calibration data
1:02:42 AMM591 D1
Pulse-type filament monitor on pin e1stop, enabled, sensitivity 10.000mm/pulse, allowed movement 80% to 120%, check every 15.0mm, no calibration data
1:02:14 AMM591 D1
Pulse-type filament monitor on pin e1stop, enabled, sensitivity 10.000mm/pulse, allowed movement 80% to 120%, check every 15.0mm, no calibration data
1:01:57 AMM591 D1
Pulse-type filament monitor on pin e1stop, enabled, sensitivity 10.000mm/pulse, allowed movement 80% to 120%, check every 15.0mm, no calibration data
1:01:30 AMM591 D1
Pulse-type filament monitor on pin e1stop, enabled, sensitivity 10.000mm/pulse, allowed movement 80% to 120%, check every 15.0mm, no calibration data
1:00:59 AMM591 D1
Pulse-type filament monitor on pin e1stop, enabled, sensitivity 10.000mm/pulse, allowed movement 80% to 120%, check every 15.0mm, no calibration data
12:59:15 AMM591 D1
Pulse-type filament monitor on pin e1stop, enabled, sensitivity 10.000mm/pulse, allowed movement 80% to 120%, check every 15.0mm, no data received

gnydick · 29 Sept 2020, 08:09

it finally triggered. I don't get it. over 31.5mm? The Drive 1 on the UI showed 200.

1:08:24 AMM591 D1
Pulse-type filament monitor on pin e1stop, enabled, sensitivity 1.300mm/pulse, allowed movement 80% to 120%, check every 15.0mm, no data received
1:08:18 AMPrinting resumed
1:08:16 AMM24
1:08:12 AMM591 D1 L1.3
1:07:57 AMM591 D1
Pulse-type filament monitor on pin e1stop, enabled, sensitivity 10.000mm/pulse, allowed movement 80% to 120%, check every 15.0mm, measured sensitivity 1.311mm/pulse, measured minimum 760%, maximum 765% over 31.5mm
1:07:55 AMPrinting paused at X154.7 Y138.5 Z3.2 U0.0
1:07:52 AMResume state saved

dc42 · 29 Sept 2020, 08:11

@gnydick said in RRF 3.1.1 M572 breaks M591:

@dc42 If the PA is not taken into account for pulsing sensor, is it taken into for the more precise sensor types that can detect retract v. exrude?

Yes.