Flow sensor for the UM2+ (and even perhaps for the UM3) - Call for pilot users

[foehnsturm 969]

What's in the package:

Flow sensor with mounted encoder, twist-lock adapter for UM2+ feeder, cable, some spare parts.

 

 

[conny_g 251]

Cool ?
Does it and how does it work with Bondtech feeders?
http://shop.bondtech.se/en/extruders/qr-30-universal_lefthand.html

 

[foehnsturm 969]

Yep, it does but you have to print different adapter. @rigs is already testing it with a Bondtech.

[tinkergnome 927]

3 hours ago, foehnsturm said:

@tinkergnome, I believe incoming signals on  A won't generate interrupts when the flow sensor is disabled?

 

@conny_g  - i guess you are using your own customized firmware anyway...? Just contact me, if you want to merge both versions, it should be easy with your expertise.

[rigs 735]

7 hours ago, conny_g said:

Cool ?
Does it and how does it work with Bondtech feeders?
http://shop.bondtech.se/en/extruders/qr-30-universal_lefthand.html

 

 

6 hours ago, foehnsturm said:

Yep, it does but you have to print different adapter. @rigs is already testing it with a Bondtech.

 

adap flow sensor bondtech.STL

 

[jffry7 12]

Hi, I have been a long time member and lurker but I think this will be my time to help the community. Sadly I sold off my UM2E clone but I have my UM3 (with bondtech DDG)

 

I know HW and solution for FW is not yet available for UM3/E but you can list me as an interested party for when UM3 test is ready. I am not an advance python programmer but can have my way on a python/arduino/c code if needed.

 

Like the others I am very excited for this project.

Edited July 17, 2018 by jffry7

[foehnsturm 969]

Well, right now I see two options for a UM3 integration.

 

A) Connecting the the encoder's quadrature signal to the electronics and enhancing the firmware in the same way as for the UM2.

 

B) Developing a tiny hardware device (< $10 arduino) which converts the quadrature signal to the I2C protocol and using (and improving)  the already integrated firmware routines for a I2C flow sensor (which have never been used for the UM3)

 

My gut feeling is that B) is the more promising.

 

   

Edited July 17, 2018 by foehnsturm

[jffry7 12]

I think the B option makes more sense if we are to make this a plug n' play solution (we dont want to brick UM3 ? ). I have a few teensy,esp32,uno,adafruit variant lying around. I think I can Frankenstein something hahaha but I havent checked the config if we can enable the flow sensor on the fly like how we change e-steps for the bondtech extruder. And I am not so expert I may need someone to point me where to start ?

 

EDIT:

many might already know this but this is good news (to me).

um3.json.log

"feature_filament_flow_sensor": false,

Just need the rest of the FW I guess

Edited July 17, 2018 by jffry7
added attachment

[foehnsturm 969]

@robinmdh, if we set this to true, the UM3 would already try to read the flow sensor via I2C? 

[uncle_bob 21]

To get the UM3 to play nice via I2C, you would need to write a driver that is specific to the target device. There is no generic protocol that "just works" in this case.

[foehnsturm 969]

@jffry7 Maybe this one already solves the hardware problem https://www.tindie.com/products/Saimon/i2c-encoder-connect-rotary-encoders-on-i2c-bus/ 

 

EDIT: Ofc just using the PCB together with our high resolution encoder

Edited July 17, 2018 by foehnsturm

[uncle_bob 21]

Usually it's better to just sit down with the hardware spec sheet and write up the code for the actual device being used. That way you reduce the number of "surprises" when things aren't *quite* the same. At least that's the answer if you do this for a living ....

 

 

[gr5 2,172]

I believe so, yes.  But I think you want to edit um3.json.  Not um3.json.log.  The file is here:

/usr/share/griffin/griffin/machines/

 

But be careful - if you accidentally delete a quote or comma or add a quote or comma you will sort-of brick the machine.  It's a lot of work to unbrick it the first time.  Requiring uncovering the linux cpu pcb and connecting either terminal cables to it or connecting a micro SD card to it.

 

[jffry7 12]

6 minutes ago, gr5 said:

I believe so, yes.  But I think you want to edit um3.json.  Not um3.json.log.  The file is here:

/usr/share/griffin/griffin/machines/

 

 

 

Thats the correct filename i used. Its just the forum wont play nice uploading.json file. It only allows other extension and .log

 

6 minutes ago, uncle_bob said:

Usually it's better to just sit down with the hardware spec sheet and write up the code for the actual device being used. That way you reduce the number of "surprises" when things aren't *quite* the same. At least that's the answer if you do this for a living ....

 

 

 

I Agree as well, we need to know if they left the procedure for the filament flow. I will dig in the rest of the files but I would be a lot easier if we have the FW or at least the copy and not play with the live printer. Tho I'll just watch @gr5 video how to unbrick I guess

Edited July 17, 2018 by jffry7

[foehnsturm 969]

15 minutes ago, uncle_bob said:

To get the UM3 to play nice via I2C, you would need to write a driver that is specific to the target device. There is no generic protocol that "just works" in this case.

@tinkergnome mentioned there's already a driver for the Allegro A1335 chip, which UM uses for the encoder. So we would have to make a copy and adapt it to the registers of the chip our adapter provides, right? 

[uncle_bob 21]

Is the chip the driver is set up for set up with the same selects and timing as the one on the flow sensor? It's grubby little details like that you have to sort through.

 

[RudydG 62]

Will there be support for the UM2 + MK2?

Then i am very interested!!

[gr5 2,172]

@jffry7 - PM me with your email if you want source code zipped up.  unbricking instructions below - I recommend you buy an unbricking cable at my website if you are in USA: thegr5store.com just in case.  It gives you console access through serial port.

 

https://ultimaker.com/en/community/51752-recovering-a-bricked-um3

 

[jffry7 12]

@gr5 thanks I will PM you thanks appreciate it. I have a few USB-to-serial but I think since yours is a tested version might be a good to have item.

 

This will help me see (i hope) what address i2c expects but I just realize I dont have any spare encoder. Maybe I should get the UM2 kit from @foehnsturm ?

 

Edited July 18, 2018 by jffry7

[gr5 2,172]

It's not usb to serial.  it's "3 pins on the olimex circuit board" to usb serial connector:

https://thegr5store.com/store/index.php/catalogsearch/result/?q=olimex

 

I stock it for convenience for USA people since Olimex only seems to sell it in Europe.  I mean you can buy it from USA but the cables are shipped from Europe so it takes a while and your printer may be bricked while you wait.  Plus I seem to remember shipping to USA costs much more than the cable.

 

I plan to sell the flow sensor kit here in the USA when it is for sale.

[jffry7 12]

On 7/17/2018 at 10:54 PM, uncle_bob said:

Is the chip the driver is set up for set up with the same selects and timing as the one on the flow sensor? It's grubby little details like that you have to sort through.

 

 

 

On 7/17/2018 at 10:42 PM, foehnsturm said:

@tinkergnome mentioned there's already a driver for the Allegro A1335 chip, which UM uses for the encoder. So we would have to make a copy and adapt it to the registers of the chip our adapter provides, right? 

 

Checking AMT103-V and A1335 have different resolution and the wheel diameter used by @foehnstrum compared to the default. I found it on marlin side of things which I am not sure yet if it can be overwritten in the python side. Need to dig deep I need Unix VM to make digging easier. If changes can only be made in the marlin side then it may be trickier to do it. As creating the driver is a lot better than reusing and overwriting all parameters. Correct me if I'm wrong.

 

thanks @gr5 for the codes.

Edited July 19, 2018 by jffry7

[foehnsturm 969]

 

Here are some basic operating instructions

 

Unscrew the lower screw that holds the feeder cover, mount the adapter (use a longer screw in case). Push the flow sensor into the mount and rotate 90°.  

It's a very good idea to use a filament guide together with the sensor. There are a lot of designs available which are mounted to the screw some 7 cm below the feeder which secures the XY stepper cover.

 

It's vital that the flow sensor wheel moves with almost no resistance when there's no filament present. 

 

 

Connect the cable as shown here. 

 

Implemented Gcode M591

 

T - extruder number T0 or T1 (default=active extruder)

S - S0 = disable filament monitoring, S1 = enable filament monitoring

E -  extrusion length for each comparison (default 0.20mm)

A - smoothing factor for exponential floating average (0.05)

L - filament movement per pulse in mm (1 / steps, default 66)

R - min/max percentage (print will be paused if the average is outside of these values)

P - set value for the average percentage

 

All parameters are optional. E and R are global (the same for both extruders)

 

Complete example:

M591 T0 S1 E0.2000 A0.05 L0.015 R40:130 P100.00

 

Basic settings

 

You can set the "L" value via the screen menu as well: Advanced / settings / filament sensor. Use "move filament", there it displays the number of encoder steps and the calculated percentage as well. Move like 10 mm and use the number of pulses to calculate the movement per pulse (most likely in the range of 0.015 to 0.017).

 

The default  E and A settings: E is quite short (0.2mm) and A  low (0.05). That means the average is calculated every 0.2mm but in the way that the new measured value only influences the result by 5%.

For calibration I use high E like 2.0 and A1.0. Then, encoder pulses and percentage match immediately.

 

Fo regular printing I found values like E0.5 and A0.3 to work well.

 

Tinkerware firmware for standard, single extrusion UM2+

 

Tinker-MarlinUltimaker2plus-18_07.zip

 

Tinkerware firmware for dual extrusion UM2+ Mark2

 

Tinker-Mark2-18.03.4.zip

The original 18.03.4 works well but after a pause and resume due to a flow sensor alert it doesn't reset the calculated flow average. This is usually hidden by the retract and prime move which helps to increase the average again. But sometimes it stays low enough to immediately trigger the next alarm.

Here's the link to a slightly modified firmware.

Tinker-Mark2-expansion-board-18.03.4fs.hex

Edited July 19, 2018 by foehnsturm

[kmanstudios 1,120]

That is sweet looking :)

[jffry7 12]

Can someone correct me and help me confirm PINOUTS for Ultimainboard?

 

First my assumption is this is i2C since 4pin, i2C and SPI seems to be interchanged on the other threads. SPI i think is better so 1 master but 4pin seem to indicate 5V, GND, SCL, SDA only. I hope not making an ASSoutUandME.

 

I tried to trace the pins but I hit a dead end.

 

from fabrc8 website

I am thinking its this pinout but just assumption. I think the 5V and the GND is correct base on the PCB trace but not sure of SCL and SDA. Or I got this completely wrong.

 

from UM GITHUB

 

But R24 and C101 is just connected to one of the PT100, this is where I hit the dead end.

 

I am hoping someone might have this pinout on hand else, I need to look more maybe a bit of coffee. ?

 

PS:

@foehnsturm I am still attempting to make the AMT103-V work I think I have the math just need to convert the signal to how A1355 works but on another thread Daid said that A1355 and new code on S5 (also in UM3) works well. Do you think this A1355 will be an alternative to you mod? The old sensor I think was AS5048B when this was in early stage of the UM3, maybe that's the unreliable one.

 

Sorry for long post.

 

EDIT: Confirmed its i2C from code

    // @brief   Constructs a device driver for the Allegro A1335 contactless magnetic angle position sensor IC.
    //          We access the A1335 over I2C. A total of 4 devices can be addressed (chip limitation) and every of those
    //          devices needs its own instance of this driver.

Now just the correct pinouts.

 

Edited July 27, 2018 by jffry7

[foehnsturm 969]

A hall effect encoder instead of the AMT is doable but would require to attach a magnetic target to the shaft and some kind of mount and housing for the PCB.  The encoder you are linking to seems to be discontinued, I'm not sure if there is a newer alternative which provides the same interface.