MK3 PAT optical sensor - Githubissues

vintagepc commented 4 years ago

Simulate the MK3 PAT sensor.

(IR sensor has been implemented, so discussions below on that are outdated... I don't see any reason to really alter the class and we will be able to simulate the different versions if we bring in the changes in #122 )

vintagepc commented 4 years ago

This is still open because while the sensor works it would be nice to offload some of the handling into a separate function as a piece of hardware with options (like board revision, and just a method call instead of explicit voltage twiddling.

vintagepc commented 4 years ago

The existing filament sensor is implemented, but longer term it'd be neat to simulate the available types.

Best hold off on starting this until after #87 as that will touch all the hardware definitions.

vintagepc commented 4 years ago

Datasheet: https://www.pixart.com/_getfs.php?tb=product&id=72&fs=ck2_fs_en

vintagepc commented 4 years ago

I think I'll take a crack at this.

vintagepc commented 4 years ago

... That is the :hankey: iest datasheet ever. Doesn't tell you anything about the config register value meanings, how many bits they have.... /sigh. Not a data sheet, a "marketing" sheet, and there's nothing better.

But on the bright side it'll give us a base class for an I2C peripheral.

vintagepc commented 4 years ago

... Is there a reason we're using bit-banged I2C for the optical sensor even though it's on the hardware I2C lines? Flash consumption? Either way, this just got a whole lot more complicated...

leptun commented 4 years ago

No idea. Maybe it is so that we can detect when the user uses the wrong printer variant.

There’s one more posibility, but I might be wrong. It is possible that they accidentally used the wrong SCL/SDA pins on the MiniRambo and had to correct them in software. If you look at the Minirambo datasheet, you’ll see that they put SCL where SDA should have beed and vice versa.

wavexx commented 4 years ago

On Thu, Jun 25 2020, Alex Voinea wrote:

There’s one more posibility, but I might be wrong. It is possible that they accidentally used the wrong SCL/SDA pins on the MiniRambo and had to correct them in software. If you look at the Minirambo datasheet, you’ll see that they put SCL where SDA should have beed and vice versa.

Uuufff. But if that was the case, I would expect a special variant for the minirambo?

wavexx commented 4 years ago

On Thu, Jun 25 2020, Yuri D'Elia wrote:

There’s one more posibility, but I might be wrong. It is possible that

Thinking again, it wouldn't surprise me if the I2C was so broken that they had to go through SW. I had the same problem twice using some low-cost sensors in the past.

vintagepc commented 4 years ago

Heh, I've been there before with a bad I2C implementation after several days of head scratching.

It's not a insurmountable issue, just an interesting one.

leptun commented 4 years ago

You can ignore my complaint that I2C pins are reversed. It is the UART2 pins that are flipped in the datasheet: https://github.com/johnnyr/Mini-Rambo/issues/4 The problem persists to this day even on the Einsy datasheet

vintagepc commented 4 years ago

Heh. Though you wouldn't even need special firmware in that case, just a cable with the wires swapped for the product in question.

wavexx commented 4 years ago

On Thu, Jun 25 2020, vintagepc wrote:

Heh. Though you wouldn't even need special firmware in that case, just a cable with the wires swapped for the product in question.

"Fix it in software"

vintagepc commented 4 years ago

I've heard that before... frustrating to no end when it makes more sense to fix it properly in hardware.

Out of sight, out of mind, since a software hackjob is less visible than a bodge wire. Until the technical debt collector comes knocking...

vintagepc commented 4 years ago

I've done what I can on this. The datasheet is just too lacking to do more; it doesn't describe the components of some key registers nor how they behave. Smells like they expect you to sign an NDA to get a full datasheet or something, there's nothing better available on the web and it's not worth the stupid amount of time it will take to reverse engineer from the PR firmware.

vintagepc commented 4 years ago

Something else is also weird - the firmware finds the sensor and will initialize it. On the menu, it will constantly read register 2 (motion) - probably autoload sensing. But, even with the sensor enabled, it stops when a print is running, so it will not sense a runout.

So about all this is good for is checking the sensor detection messages.

leptun commented 4 years ago

Maybe it only polls the sensor during E motion when printing and always when waiting for autoload.

vintagepc commented 4 years ago

I had started a virtual print, so there was definitely E motion.

leptun commented 4 years ago

Does I2C support multi-master mode? Or maybe this specific SW implementation?

vintagepc commented 4 years ago

Does not look like it

3d-gussner commented 4 years ago

AS you changed the MK404 a bit it will take some time for me to understand where what is and how I can change/contribute bit more.

vintagepc commented 4 years ago

Hopefully that won't happen again, I think this should be a fairly maintainable going forward. If it helps give a broader sense of organization:

parts/boards: "board" definitions, i.e. physical wiring for EinsyRambo, MM control board to setup the components and wiring
parts/components: "hardware" definitions for bits and pieces
parts/pinspecs: Lookup tables for timer/port/bit for a given digital pin number
parts/printers: Printer layers on top of boards. this has all of the interaction and visual components to a printer.
parts/wiring: lookup tables from convenience/common names to pin numbers- lets you write shared code using a pin name which will work on any board that implements the same convenience pin.

vintagepc commented 4 years ago

It occurs to me that perhaps the secrecy is due to some sort of laser regulations as the device contains an IR laser diode... and according to the PFW, a bank of additional undocumented registers.

vintagepc commented 4 years ago

I made some progress here - the autoload now works correctly. But it's not polling the sensor during a print.

I see the code for this sensor sets up an ISR on pin PJ4. Am I correct we're toggling an unused pin to trigger an ISR fsensor update?

leptun commented 4 years ago

I’ll check the code tomorrow. I want to think that you are wrong, but that’s probably not the case.

vintagepc commented 4 years ago

Hate to break it to you, but yep, that's what we're doing. The reason it doesn't work is SimAVR doesn't setup the PCINTs on PJ or PE0.

vintagepc commented 4 years ago

Huh... well, I see why. the 2560 has the higher PCINTs defined a little weirdly, with 8 on E0, and 9-15 on J0-6. That's incongruent with the simavr PCINT handling code.

vintagepc commented 4 years ago

Fixed. I believe the PAT implementation is minimally functional at this time - I was able to get working autoload and runout detection during a print. :tada:

3d-gussner commented 4 years ago

I will give it a try.

3d-gussner commented 4 years ago

Toggling "f" works, but:

If printer isn't printing and "f" toggle sets filament to present
- the Yd: counter runs constantly (Support -> Extruder Info) and runs in an overflow.
- I have to collect some data from the real PAT9125 what it is doing during a print.
- the Fil. autoload never stops, but this could be an firmware issue. With the MK3s IR sensor you get the Preheat menu but you can just click to quit the preheat menu.
During the print
- The Support -> Extruder info menu shows no action
- If filament is present "f" toggle, then the Yd counter should move with extruder feedrate
  - feeding should result in positive counter
- Would be great if we could get "j" JAM toggle for this one. But that is something for later
- While the extruder is retracting the Yd should be a negative counter
  - if that is longer (unload length) it should stop.

I could not simulate a filament run out during a print.

This was a short test with moving filament in and out on PAT9125 https://youtu.be/mmikmd2Uu4M?t=19

vintagepc commented 4 years ago

The first part may be a flaw in the design. It's stet to stop "ticking" the y delta as soon as the extruder moves and reports a "real" distance value to the printer. When the extruder is moving, the E value is directly coupled to the sensor and any offsets it reports should be based on that motion.

The non functional behaviour during the print is consistent with what happened in the earlier SimAVR build. make sure you git submodule update to pull the correct version that has fixed the missing PCINTs on port J.

3d-gussner commented 4 years ago

Updated submodules and the filamlent run out "f" toggle during print generated a M600. :+1: It looked like it was taking quite some time to get there (could be the Prusa-Firmware). IR sensor triggers M600 very fast. Thanks for the fast answer and getting MK404 so good.

vintagepc commented 4 years ago

yes - the old sensor does a measurement (OQ) by moving the filament up and down to see if it really ran out, this takes a few seconds. With the IR sensor we basically know it is out as soon as it trips.

This is quite a neat little sensor, kind of a shame it's been plagued with reliability issues due to firmware bugs and just not working with the MMU very well.

They don't use the same pins, maybe one day it'd be neat to see a mod that uses both sensors - IR for runout and MMU load, laser for jam detection.

3d-gussner commented 4 years ago

@vintagepc Tried to create a Prusa_MK3MMU2 option. Can you check https://github.com/3d-gussner/MK3SIM/tree/Prusa_MK3MMU2 if I missed something?

3d-gussner commented 4 years ago

yes - the old sensor does a measurement (OQ) by moving the filament up and down to see if it really ran out, this takes a few seconds. With the IR sensor we basically know it is out as soon as it trips.

Thought so that the Prusa-Firmware for PAT9125 would handle it differently.

This is quite a neat little sensor, kind of a shame it's been plagued with reliability issues due to firmware bugs and just not working with the MMU very well.

Yes it is. But if I am not wrong @wavexx did some great improvements to the Prusa-Firmware.

They don't use the same pins, maybe one day it'd be neat to see a mod that uses both sensors - IR for runout and MMU load, laser for jam detection.

Exactly what I was thinking too.

To get reliable readings from the PAT9125 I was thinking to add a bearing with rubber (like paper feeders in 2D printers but with steal bearings).
- As the PAT9125 can detect tiny rods rotation (in watches) it should be able to detect a steal bearing as well.
- reading Yd (filament movement) for jam detection (filament rolling against rubber on steal bearing)
- reading Xd for diameter measurement. (motion of the bearing)

The IR is a fail safe or additional sensor to detect runouts.

As the P3 connector on Einsy has all needed PINs a y cable to PAT9125 and IR is easy to make.

Only Issue is that the PAT9125 code uses bit more resources compared to a "simple" switch;-)

vintagepc commented 4 years ago

Yes - absolutely, I don't doubt there have been improvements since the earlier version. But it's an uphill battle after initial bad experiences folks may have had. The messed up planner buffer after a false runout was a major issue for a while.

I did indeed run a "bearing mod" skelestruder briefly and it was reliable. But of course I had to get rid of it due to getting an MMU2... the length calibration was just painful. (Though the door sensor setup for the skelestruder can be rather finicky too...)

Looks like you hit all the main points for the MK3 variant - Were you running into specific issues or did you just want a general review of the implementation?

My personal preference (for reduced code copy-paste) would probably be to do it the same way we have the MK3S->MK3 handling, e.g. rather than copy-pasting the MMU code to a new file, inherit from (: public MK3SMMU2) the 3SMMU2 and overload the SetupIR and ToggleFSensor the same way we do in the MK3 .h file.

vintagepc commented 4 years ago

I pushed up a fix so it doesn't "nudge" the filament endlessly on autoload if the E axis doesn't kick in.

3d-gussner commented 4 years ago

My personal preference (for reduced code copy-paste) would probably be to do it the same way we have the MK3S->MK3 handling, e.g. rather than copy-pasting the MMU code to a new file, inherit from (: public MK3SMMU2) the 3SMMU2 and overload the SetupIR and ToggleFSensor the same way we do in the MK3 .h file.

Is this better ? https://github.com/3d-gussner/MK3SIM/commit/8646f7633c0bcbcd661154e70d517644623340bc

vintagepc commented 4 years ago

Yep, that looks about like what I'd have done.

vintagepc / MK404

MK3 PAT optical sensor #7