How to support a position aware feeder

[AE's Life]

Hello Openpnp group,

I have been converting my 3D printer to pnp machine using openpnp (thanks for creating it!), and created different type of feeders (normal and auto version) , because of limited space, I have to place them side by side on the base plate, it is tedious job to setup those feeders.

So I am in the process of making a position aware base plate and feeder with help from an experienced engineer, basically when user plug in the feeder, base plate will report position, type of feeder, pitch, holding components and possible how many components left etc., then on openpnp side, we are hoping that those info will then be digested by openpnp and show up in feeder session. The same story when it is removed. 

What we currently thinking is providing an USB to serial interface, that can support command of reading all feeders for ex. Then on openpnp side, we are wondering what will be the best way to do that? ex. will it be possible to say every start of the job to read in all feeders info, or maybe a refresh button. And if we want to add the support, where to look in the solution, thanks in advance!

Best regards,

xp Liao

[Jonathan Oxer]

It's not a direct answer to your question, but perhaps a place to investigate is the way Opulo integrated support for the Lumen PnP feeders into OpenPnP. They've created a feeder control protocol called Photon that they hope will be used by other people in their own feeders, to facilitate things like feeder auto-discovery through OpenPnP. They use RS485 to connect all the feeders on a single bus, and run the Photon protocol over it to interrogate feeders, set options, and control them.

General notes about the design decisions related to their feeders are here:

https://github.com/opulo-inc/feeder/blob/main/DESIGN_DECISIONS.md

Because each feeder has its own ID, once a feeder has been configured it's possible to plug it into a random location on the feeder bank and OpenPnP can autodiscover which feeders are loaded.

Cheers

Jon

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/e0b6d60f-a578-4f65-99be-edbf920731c6n%40googlegroups.com.

[Mike Menci]

Helo Liao, 

Just to let you be aware that Siemens Schultz feeders have feature in Open PnP for ; 

• GetID
• Pre-Pick (open shutter)
• Post-Pick (advance tape)
• AdvanceIgnoreError
• GetCount
• ClearCount
• GetPitch
• TogglePitch
• GetStatus

The Arduino Every Nano was used to interface Feeders with OpenPnP - its Open for use and you can find it here; 

https://github.com/bilsef/SchultzController/wiki

and the code work starts : https://github.com/bilsef/SchultzController

Might be a good starting point for your needs. 

[mark maker]

Hi xp Liao,

amazing miniaturization. Congrats!

For real position awareness of the kind your are describing you would need to write new "discovery" code. There are some existing capabilities in OpenPnP, but I don't think any of them would really bring out the advantages of your design.

Discovering at the beginning of the job or with the press of a button would be no problem. Automatic triggering when plugging in the feeder is harder in OpenPnP, I guess. So my advice would be to design a scan-and-report routine, which OpenPnP could then work with. Adding such a routine in Java would not be hard, IMHO, and I could perhaps help (assuming Open Source, Open Hardware).

Full plug-in position awareness from the plate sounds ambitious/expensive. Did you ever consider the nozzle going across the feeders, and using the feeder's proximity sensor to know which feeder should report its data, then using the nozzle's position for location?

_Mark

[AE's Life]

Hello,

Thanks for sharing the info and thoughts, currently our design is a bit of mix of both photonFeeder and the Siemens Schultz feeders ways, we have feeder with i2c reading the position info from baseplate, then report to a mcu on baseplate, then this mcu will interface openpnp, right now it seems possible to provide the usb to serial interface, so openpnp can use that as gcode driver.

@Mark Thanks for the thoughts and the offer, we indeed plan to open source the feeder + baseplate design (hw, sw and 3D design). One question is if we provide the USB to serial interface, will that be good enough for scan and report? I assume In the firmware we need to react to some gcode command.

For the cost, we plan to make it low, for ex. we are checking the py32 mcu, which is arm m0, very low cost, the same we control for other components as well. It is a bit ambitious, but I think it will be worth a shot!

We will update if we get boards setup.

Best regards,

xp Liao

Sent from Outlook for Android

---

From: 'mark maker' via OpenPnP <ope...@googlegroups.com>
Sent: Sunday, October 29, 2023 9:11:40 AM
To: ope...@googlegroups.com <ope...@googlegroups.com>
Subject: Re: [OpenPnP] How to support a position aware feeder

 

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/da65986f-24f6-45ef-81fe-84d19a01da32%40makr.zone.

[mark maker]

> One question is if we provide the USB to serial interface, will that be good enough for scan and report?

Yes, as long as works with text lines (not binary), and command/response, I see no problems. It does not need to be G-code, anything textual with decimal numbers is fine. But if you write the firmware yourselves, I recommend adopting a G-code like syntax and implementing M115 for discovery of the firmware type, which you can use with I&S to auto-setup.

> with i2c reading the position info from baseplate

Sounds complicated. How many contacts per feeder do you need? How do you plug them in reliably? How much does a connector cost?

I'm just asking because your current feeder (the one shown on YouTube) is actually very much following the K.I.S.S. principle with the proximity sensor feed impulse, tape transport by pulling on the protective film (just one motor needed), its autonomous nature, etc. I very much like that.

So in that spirit, I hope you'll keep true to that principle, and plan to extend on it 🙂.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/GVXPR10MB8154A78E679FD016B52D8D8EA4A2A%40GVXPR10MB8154.EURPRD10.PROD.OUTLOOK.COM.

[AE's Life]

>Yes, as long as works with text lines (not binary), and command/response, I see no problems. It does not need to be G-code, anything textual with decimal numbers is fine. But if you write the firmware yourselves, I recommend adopting a G-code like syntax and implementing M115 for discovery of the firmware type, which you can use with I&S to auto-setup.

Yes, we plan to code our firmware, so will look into G-code syntax.

>Sounds complicated. How many contacts per feeder do you need? How do you plug them in reliably? How much does a connector cost?

We plan to have 5 contact initially, 1 for getting location info from baseplate, 2 for i2c for talking to baseplate mcu, and 1 pwr + 1 gnd, we are using POGO pin, and Lego baseplate will limit the position when plug in, so should support reliable contact. In Aliexpress it is about 0.5 eur.

we are looking into 4 pin solution as well, that is getting 1wire protocol to talk to baseplate mcu, then 4 pin connector will be even cheaper and easier to source.

>So in that spirit, I hope you'll keep true to that principle, and plan to extend on it 🙂.

yep, we design in modules, circuit is quite simple, so will stick to it to make our life easier.

 BR

xp Liao

[DoTheDIY (Apoorv Chaudhary)]

Opulo uses a 1 wire eeprom in base plate u can use the same design. Eeprom will have a unique address which will be mapped to a location 

[AE's Life]

Thanks for the info, we reserved one pin for the addressing, could be EEPROM or resistor dividing, one thing is the one wire EEPROM is a bit expensive, especially if we count 50x or more, so we are checking both solutions.

BR,

xp Liao

Sent from Outlook for Android

---

From: ope...@googlegroups.com <ope...@googlegroups.com> on behalf of DoTheDIY (Apoorv Chaudhary) <apoo...@gmail.com>
Sent: Monday, October 30, 2023 2:25:08 AM
To: OpenPnP <ope...@googlegroups.com>

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/f93188a2-dd71-4c46-bf6a-86620fb5e92fn%40googlegroups.com.

[DoTheDIY (Apoorv Chaudhary)]

0.24$ for one pc does not look much https://www.mouser.com/ProductDetail/Microchip-Technology/AT21CS01-STUM10-T?qs=9KdFJXLqUo%2FgMylLarQTuA%3D%3D and 50 pcs will cost close to 10$.

Also, u can opt for ESP8266 or a cheap MCU since you are not using any wireless capability of the ESP32 that will bring in the major cost saving.

[AE's Life]

We have the baseplate that we want to provide the flexibility for mounting, so $0.24 is a good option indeed.

For the MCU we plan to use PY32, that is an Arm chip that looks promising, we will test it first and see it fits.

BR

xp Liao

[AE's Life]

Hello Mark,

While designing the PCB, some questions came up, 

I plan to provide 2 Gcode, M115 as you stated previously, 

then another M code to return an array of feeders, so what info would be interesting for openpnp, I can think of

* Position of feeder (relative to the bottom left corner of baseplate for ex., can openpnp use this position and convert to its coordinate system? do we need a home fiducial component that can return position?)

* width, length, Height of the feeder (do we need all these dimensions?)

* Component info (name, tap pitch, tape width, rotation in tape)

* status (is it in error state, is it reaching the end. ex.)

Do you see any other info needed?

Also What would be the suitable period for openpnp to query status?

Best Regards,

xpLiao

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/db24e863-0807-4da9-b7fe-4556065755ca%40makr.zone.

[mark maker]

Hi xpLiao,

just to be very clear: You will have to program this into OpenPnP in Java. Or use the scripting support of OpenPnP. So it is basically you, who says what you want to do. OpenPnP has no such functionality yet.

Personally, I would use OpenPnP to store component info. I would use some constant UUID in the feeder (MCUs typically have them) to associate the feeder with the part. This way you don't need to program parts into the feeder, which would require a second program, 

Think about the workflow: I assume parts are already automatically imported from the ECAD into OpenPnP, so they are available and can be selected from a drop-down, which eliminates any typos there.

If a feeder is listed for the first time, OpenPnP would just create the feeder in OpenPnP with the part unassigned. The user can then   select the missing parts (that's already how it works in OpenPnP). By storing the UUID on the feeder, OpenPnP then always knows which part is loaded in the feeder. Plus all the other associated info from the ECAD or entered by the user.

The coordinate system is tricky. You would somehow have to enter at least three corner-points of the plate in OpenPnP, I guess. Maybe you would even want to support multiple plates?

I would not query the status unless prompted by the user. But you can enforce it in the job preparation handler.

_m

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CANbLAndHg1Z2GifXWZUDGJnsinU_dQUL2_aBT5NH0arzKhYaEQ%40mail.gmail.com.

[AE's Life]

Hi Mark,

Thanks for replying,

>just to be very clear: You will have to program this into OpenPnP in Java. Or use the scripting support of OpenPnP. So it is basically you, who says what you want to do. OpenPnP has no such functionality yet.

ok, that is clear, my expectation is to seek support while lost in code somewhere.

>Personally, I would use OpenPnP to store component info. I would use some constant UUID in the feeder (MCUs typically have them) to associate the feeder with the part. This way you don't need to program parts into the feeder, which would require a second program, 

>Think about the workflow: I assume parts are already automatically imported from the ECAD into OpenPnP, so they are available and can be selected from a drop-down, which eliminates any typos there.

>If a feeder is listed for the first time, OpenPnP would just create the feeder in OpenPnP with the part unassigned. The user can then   select the missing parts (that's already how it works in OpenPnP). By storing the UUID on the feeder, OpenPnP then always knows which part is loaded in the feeder. Plus all the other associated info from the ECAD or entered by >the user.

make sense. I guess it will be similar to what PhotonFeeder has, when new feeder installed, then press button and assign parts.

>The coordinate system is tricky. You would somehow have to enter at least three corner-points of the plate in OpenPnP, I guess. Maybe you would even want to support multiple plates?

Indeed switching plate is interesting use case. If there are pre-printed fiducial on the plate with known coordinates (relative to plate), and user use camera to find out its position, then it should be able to get the offset and rotation of the plate I assume. 

When feeder return position, then it can be mapped to Openpnp coordinate. But I am not sure where this step should happen, maybe a button in feeder setup UI to calibrate plate position, and the result will be globally useable?

BR

xpLiao

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/97d331ec-6ca6-4143-b91c-05541193c364%40makr.zone.

[mark maker]

Hi xpLiao,

the problem with fiducials on your design is that they are at drastically different Z heights. So they will almost certainly be too blurred, and the camera parallax might be too large for any kind of precision. Plus the feeders are likely to have some wiggling room if still plugged in LEGO-like.

So perhaps you will have to mount fiducials on some structure rising up to the feeder surface level. Perhaps the plate would be more like a crate, with a wall around it. This would also align the feeders.

Another approach would be to forget about the plate and use the feeders themselves for position (sprocket hole vision, as you already use). The user would have to jog to the first few feeders, until OpenPnP can derive the grid from the feeders it already knows, taking their position data into account. It should be possible to interpolate/extrapolate from existing feeders, gradually improving the accuracy. The advantage of that is that all information can be stored on the feeder, no extra GUI for "plates" is needed.

This is pretty much how the "+" button on the ReferencePushPullFeeder already works, for rows of feeders. I assume you have watched the video there:

https://youtu.be/5QcJ2ziIJ14?feature=shared&t=295

Storing and synchronizing common attributes, like the overall plate dimensions, and the actuator getting its report, for a whole array of feeders is also done in the BlindsFeeder. You could look into that code.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CANbLAneXP6GjvOS%3DGuaQwGZOX_yrVgEz6c8LuwzT9vU_apRcgw%40mail.gmail.com.

[AE's Life]

Hi Mark, 

Thanks for pointing out the references, I think the '+' button of referencePushPull feeder is what I was looking for, with that you automatically created the feeder for the next one with everything setup, this is nice, that could work in my case. 

Also the OCR is brilliant, that makes setup easier. Will look into those and see what I can get out of it.

For the fiducial I do make sure they have the same height as the feeder pick and PCB surface as suggested in openpnp wiki, maybe <1 mm difference due to different PCB thickness.

The 12mm feeder does have room for wigging, I usually put multiple side by side to support, I think there still room to improve, like some support structure as you mentioned. The 16mm+ ones are better on the other side, I will see what I can do to improve there as well.

Best regards,

xpLiao

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/ccb68535-d366-4a68-b924-a031850ae5f9%40makr.zone.

[AE's Life]

Hello all,

Thanks for the suggestions on the topic, I have made some progress on the position aware feature (https://www.youtube.com/watch?v=Ypybq_xlA0o), 

As I found OpenPushPullFeeder has really powerful features, I inherited from it to reuse the behavior, and added a tab for auto feeder detection, as it is still work in progress, there will be still bugs, and appreciate any comments, I have made a fork https://github.com/xpDIY/openpnp

One thing I noticed is that for different tabs of a feeder, if I made modifications, I need to click apply for each tab separately, just wondering is there any reason behind this behavior? 

It would be handy if the user clicks on one apply and all the changes will be saved.

Best regards,

xpLiao

[mark maker]

Brilliant! 

How exactly does the feeding work? By proximity or through the same electronics that discovers the feeders?

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CANbLAneHqGVkRJRrv5AtA-sn2Nk%2BvvdMA6f%2BfPmjjtoLJ5nVFQ%40mail.gmail.com.

[AE's Life]

Hi Mark,

I have implemented a G-Code in the feeder's firmware, so OpenPnp can control it, it is through the same electronics that discover the feeder. 

The feeder component (CassetteFeeder) in OpenPnp will configure the G-Code during discovering phase, so the user doesn't need to setup manually. 

Here is the branch https://github.com/xpDIY/openpnp/tree/orientationDetection.

BR

xpLiao

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/06a6f5c4-9ad4-47a2-854a-4e3b63b70435%40makr.zone.

[SM]

Small is beautyful.
How many layers does the strip board have?

[AE's Life]

It is a 2 layer board, a bit tricky to route the PCB, but 2 layers get a really good price from PCB manufacturers!

BR

xpLiao

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/90899bc4-397c-471d-9979-22d4d3869a18n%40googlegroups.com.