Regex Woes

[Duncan Ellison]

Hi Guys,

What have I not understood about reading the vacuum using regex?  I've tried to follow the tutorial, but can't seem to return a value.

I have Head 1 - Nozzle 1 - ACTUATOR_READ_COMMAND set to M803

I have Head 1 - Nozzle 1 -  ACTUATOR_READ_REGEX set to (?<Value>-?\d.\d+)

Actuating H1N1_VAC > Read Value successfully issues the M803 (see log below), the Smoothie answers with  ok T:inf /0.0 @0 but the value returned seems to always null.

2019-12-31 14:03:27.372 GcodeDriver DEBUG: sendCommand(M830, 10000)...

2019-12-31 14:03:27.373 GcodeDriver TRACE: [serial://COM3] >> M830

2019-12-31 14:03:27.374 GcodeDriver TRACE: [serial://COM3] << ok T:inf /0.0 @0

2019-12-31 14:03:27.375 GcodeDriver DEBUG: sendCommand(serial://COM3 M830, 10000) => [ok T:inf /0.0 @0]

2019-12-31 14:03:27.375 ReferenceActuator DEBUG: N1_VAC.read(): null

I tested the regex with an online tester and it matches 0.0.

BTW, I know that I should really be reading the part that says 'inf' which presumably means 'infinite' as I haven't got the actual sensor hooked in yet.  I'm assuming also that null really means null and not 0.0

I just got two very nice Panasonic sensors today, but found out that they only switch rather than deliver an analogue representation of the vacuum, so I'm going to have to use 0V or 5V from the NPN driver as the part on / part off sense :-(

Duncan

 

[Jason von Nieda]

Hi Duncan,

You have to match the entire string, or at least the beginning up to the part you want to capture.

I have an example you can experiment with here: https://regexr.com/4pvqj

So, in your case you can try something like "ok T:inf \/(?<Value>-?\d+.\d+).*". When you get the sensor hooked up and that Inf changes to something else, you'll need to modify it a little, but it should be clear what it should be.

Jason

--
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/28d1bdb1-2f87-4d18-84f8-817f7c0da843%40googlegroups.com.

[Duncan Ellison]

Thanks Jason :

2019-12-31 17:37:55.778 GcodeDriver TRACE: [serial://COM3] >> M831

2019-12-31 17:37:55.779 GcodeDriver TRACE: [serial://COM3] << ok T:inf /0.0 @0

2019-12-31 17:37:55.780 GcodeDriver DEBUG: sendCommand(serial://COM3 M831, 10000) => [ok T:inf /0.0 @0]

2019-12-31 17:37:55.781 GcodeDriver TRACE: actuatorRead response: ok T:inf /0.0 @0

2019-12-31 17:37:55.782 ReferenceActuator DEBUG: N1_VAC.read(): 0.0

All smiles now :-)

Damn, but I hate Regex.  I have an Honours degree in Computer Science and I still can't get my head around them.

Duncan

To unsubscribe from this group and stop receiving emails from it, send an email to ope...@googlegroups.com.

[Dave McGuire]

On 12/31/19 9:09 AM, Duncan Ellison wrote:
> I just got two very nice Panasonic sensors today, but found out that
> they only switch rather than deliver an analogue representation of the
> vacuum, so I'm going to have to use 0V or 5V from the NPN driver as the
> part on / part off sense :-(

I feel your pain. Just last night I went through my drawer of
pressure and vacuum sensors for over two hours looking up datasheets and
such. Not a single one was the right type or range for this.

So sitting here with a drawer full of what has to be at least a
thousand bucks' worth of pressure sensors, I've gotta drop $15 on
another one. Sigh.

-Dave

--
Dave McGuire
McGuire Scientific Services, LLC
New Kensington, PA

[Airhead Bit]

I was looking into adding a vacuum sensor and found: MPRLS0015PA0000SA  in another post here, $6.78 Digikey with connector and regulator + PCB about $11.00, it is very sensitive and uses I2C protocol, I'm changing the 3.3 regulator to a DFN6, cost more but reduces the PCB size, also getting rid of the third fiducial. This is a 3.3 volt device, not for use on a 5 volt project without level shifting. I'll get the boards back 'next year'...

[Dave McGuire]

On 1/1/20 12:07 AM, Airhead Bit wrote:
> I was looking into adding a vacuum sensor and found: MPRLS0015PA0000SA 
> in another post here, $6.78 Digikey with connector and regulator + PCB
> about $11.00, it is very sensitive and uses I2C protocol, I'm changing
> the 3.3 regulator to a DFN6, cost more but reduces the PCB size, also
> getting rid of the third fiducial. This is a 3.3 volt device, not for
> use on a 5 volt project without level shifting. I'll get the boards back
> 'next year'...

And, happy new year!

So it looks like the sensor you found only does positive pressure, not
vacuum...where were you going to use this, again?

[Simon Merrett]

Can't one use the BMP180 etc as a vacuum sensor for part attached/detached sensing? Or is their interface too slow? AFAIK their 30 hPa lower limit would be useful, even if some vacuums would have a lower absolute pressure than this.

[Dave McGuire]

On 1/1/20 6:09 AM, Simon Merrett wrote:
> Can't one use the BMP180 etc as a vacuum sensor for part
> attached/detached sensing? Or is their interface too slow? AFAIK their
> 30 hPa lower limit would be useful, even if some vacuums would have a
> lower absolute pressure than this.

I would think that the 30hPa limit would be a problem on some
machines, but perhaps not all.

How would you couple it to the vacuum system? Some sort of tiny
air-tight enclosure perhaps?

[Simon Merrett]

Yes, you'd have to come up with something to enclose it while escaping the four conductors, although there are plenty of options for that. Hot glue the module into a port near the pump?

[Michael Anton]

Using a gage sensor would probably make sense so that you don't have to worry about changing atmospheric pressure.

If you use the long tube version, you can probably get a piece of flexible tubing to stay attached.  This is measuring vacuum, so it will tend to want to stay on.

[Simon Merrett]

Michael which gauge sensor would you recommend? For the price and availability an absolute atmospheric range sensor could easily tell the difference between atmospheric pressure and a pnp vacuum, especially if it ran a calibration reference measurement when the pump was unpowered on startup.

Keen to hear about alternatives though.

[Mike M.]

I am using SMC with display - programable,.. with analog output

https://rover.ebay.com/rover/0/0/0?mpre=https%3A%2F%2Fwww.ebay.com%2Fulk%2Fitm%2F202782376036

And switch as hight sensing
Mike

[Mike M.]

I can check the model code tomorrow if somebody is interested ...
Mike

[Dave McGuire]

On Wednesday, January 1, 2020 at 5:47:18 PM UTC-5, Mike M. wrote:

I can check the model code tomorrow if somebody is interested ...

  Hi, yes please, I'd like to know the model you're using.

              Thanks,

[Michael Anton]

I think you could just use one from the same series that Airhead Bit was looking at.  Likely the MPRLS0015PA0000SA would be fine, and is the same price.  The 15psi gage ones should be able to read +-15psi, though they don't seem to state that in the datasheet, but it wouldn't make sense if they could only read positive pressure.  The result that is returned, appears to be signed at least, so it should be able go negative.

Yes, there is no reason that you couldn't take a reference reading now and then (you might want to do that even for a gage sensor for zero compensation).  It would just be easier to use a gage sensor, which also does it more accurately.

[Michael Anton]

Oh, if you do use a gage sensor, make sure you put a hole in the PCB in the correct location to provide the atmospheric pressure reference.  This also means that the board will need to breath, and can't be potted.

[Airhead Bit]

That sensor is an absolute sensor as used in PSIA measurements, the gauge sensor is also available, gauge sensors provided the negative measurement you are looking for as in relative measurement but requires a hole in the PCB where you place the sensor, no big.

An absolute sensor measures the absolute pressure to zero, which means no pressure, no pressure means vacuum. If you look at vacuum pumps they are rated at ~ 10 CFM and pressure as in 5Pa, but never negative. Just ordered some dI2C extenders, HWSON8 3X3mm package for $0.98, 1Mhz @3 meter.

What needs a negative measure?

Kevin

[Michael Anton]

I made a mistake in my post above, and meant to suggest part number MPRLS0015PG0000SA, which is a gage sensor.

The problem is that an absolute sensor will measure atmospheric pressure, and always read a positive value.  Atmospheric pressure is not stable, so unless you do gage compensation by zeroing out the atmospheric pressure reading, you don't know the actual vacuum as measured against atmospheric pressure.  A gage sensor does this for you.  A gage sensor will read as a negative number when exposed to a vacuum (pressure below atmospheric pressure), which is why I too made the negative number comment.  So, if we are talking about readings relative to atmospheric pressure, vacuum will read negative, and pressure above atmospheric will be positive.

Ultimately, the force holding a part to the nozzle is related to the difference in pressures between atmospheric pressure, and the partial vacuum pressure.  So, you really want to know the pressure below atmospheric pressure, rather than an absolute pressure that is relative to a perfect vacuum.  Using a gage sensor allows you to set up a threshold to determine if there is a part on the nozzle or not, without having to worry about drift of the values due to atmospheric pressure changes.

What kind of pumps are you looking at that are rated at 10cfm at 5Pa?  That is one huge pump if that is an absolute pressure, and would probably be far too large for a PnP machine.

[Mike M.]

Hi Dave,

See details of SMC with data enclosed.

Mike

[Mike M.]

I use two Model: SMC ZSE40A-01-R-M

Analog output + two switch configurable settings for vacuum.

https://www.smcpneumatics.com/ZSE40A-01-T.html

Mike

[Marek T.]

www.nxp.com/docs/en/data-sheet/MPXV6115V.pdf

Gauge and not any single word about the under body hole requirement...

Michael, do you think that gauge can be slower than absolute, or otherwise? I mean the speed of reaction (response for changes).

[Michael Anton]

The datasheet that you linked to indicates that there is a port on the bottom side of the sensor, so you wouldn't be able to seal up the backside of the sensor.  This application note: https://www.nxp.com/docs/en/supporting-information/DL200.pdf, may shed more light on this, but I haven't read through all of it.  There are many cross sectional drawings and notes that talk about the P2 port of the gauge sensors.

I don't see why a gauge sensor would be slower.  An absolute sensor just has a vacuum pocket on the other side of the element.  As long as the reference side of the sensor is allowed to track atmospheric pressure changes without any lag, I don't see why they would be any different.  In the case of these sensors, they would both use the same electronics, and I would think that that would be where most of the delays would occur during measurement.  Response time should be pretty quick in either case.

[Michael Anton]

My commercial PnP uses sensors similar to the SMC ones you are using.  In my case, they are a pair of Keyance AP-21A gage sensors.  These have two thresholds that can be set internally, to trigger two open collector outputs.  Each of the thresholds are used for different nozzle sizes, with one used for the smallest nozzle, and the other used for all other larger nozzles.  For the most part, they work pretty well, but this doesn't give per part type settings, which would be the advantage of a sensor with an analog output.

[Marek T.]

1080 pages...:-), I'll go through this later. I didn't make a hole but can't see problems, expect the one the system is not to fast reacting in the moment of the pump (valve) on/off. But I don't know is the sensor slow or the pressure (vaccum) is just changing slowly. The fact is that my original philips solution works much much faster (there is 0/1 output from the sensor module and the threshold is adjusted manually with pots).

I thought the same about the speed, responses things. Just was curious that maybe practice is not in agree with theory expectation in this case.

[Michael Anton]

You can scroll down to the section on pressure sensors, which speeds up the reading process... :-)

Response time will depend on what volume of air needs to be evacuated.  Larger volume hoses will take longer to reach a given pressure than smaller volume hoses.  The pressure sensors on my machine are located right at the vacuum source.  Probably the ideal would be to mount them at the nozzle, as then you are reading the pressure as seen at the nozzle (which is what we mostly care about), and not at the end of a hose, which will not be the same reading if there is any air leakage.

[Marek T.]

Scrolling was the plan, but on mobile now :-).

I have ventouries on the movable head and the sensors the same. Between the tip and sensor I have 25cm 4mm hose + 20cm of the nozzle holder construction. Inside this "construction" there is a field to limit the diameter and the volume of air this way. But main problem is the Juki holder with balls that must leak to keep the nozzle well. So next step to test is to seal the balls with gum band instead of original metal balls presser. Pain is weaker nozzles holding then.

[Airhead Bit]

https://www.amazon.com/SMC-ZSE40A-01-R-M-X501/dp/B07V5G3NGJ?SubscriptionId=AKIAILSHYYTFIVPWUY6Q&tag=duckduckgo-ffab-20&linkCode=xm2&camp=2025&creative=165953&creativeASIN=B07V5G3NGJ

Yikes!

$250 each? You paid $500 for pressure readings?

On Thursday, January 2, 2020 at 1:57:57 AM UTC-7, Mike M. wrote:

Hi Dave,

See details of SMC with data enclosed.

Mike

-------snip

[Airhead Bit]

https://www.digikey.com/products/en/sensors-transducers/pressure-sensors-transducers/512?k=MPRLS00

https://www.digikey.com/product-detail/en/honeywell-sensing-and-productivity-solutions/MPRLS0015PG0000SA/480-MPRLS0015PG0000SACT-ND/10231664

Look at the Part Status

The PCB with new regulator but missing mounting hole, only works with 3.3 volt devices. I'm doing a new layout including the dI2C part which also allows I/O voltage selection as in work with 5 or 3.3 volt devices, you need a pair of the dI2c devices for the sensor..

-----snip

[ma...@makr.zone]

  Hi, yes please, I'd like to know the model you're using.

Don't know where this thread is really headed now, and if "DIY" is an option, but some readers might also be interested in a simple/affordable option like this:

https://makr.zone/vacuum-sensor/192/

_Mark

[Airhead Bit]

"simple/affordable" that sensor in your link is $20 at Digikey.com - include the op-amp and parts that seems like an expensive vacuum sensor solution.

The Honeywell sensor is I2C based, the code can be added to smoothieware or merlin (if its not already there) to respond to M codes.. for smoothieware: http://smoothieware.org/smoothie-accessory-protocol  Mirlinfw.org has M260&261 send I2C & receive I2C but smoothieware does not http://smoothieware.org/supported-g-codes

Why not add an M code definition that allows OpenPnP to read I2C based Vacuum sensors, the same M code for all G code firmware by adding it to the different G code firmware? There are a couple of M codes left :)

I'm still working on figuring out OpenPnP and the different controller boards that are around so if I've said something incredibly stupid and offended someone, I repeat, still learning and at my age I may forget a lot...

[Mike M.]

Hi Airhead,

I purchased two used ones from eBay @15.00$ each+postage which is less than new sensor cost is.

Marek - see DL200 date page enclosed.

Just a note: If you are having more than 1 nozzle and using one vacuum pump readings will vary - test it out if you dont belive me.

Venturi or ejector system might work.

Mike

[Marek T.]

Mike, I have one large compressor (not vacuum pump) 5atm in 300litres reservoir tank, and three ventouri microejectors before each of three nozzles. Sensors between microejectors and nozzles.

[ma...@makr.zone]

"simple" as in use an unmodified Smoothieboard (or other) thermistor input.

"affordable" as compared to the industrial solutions discussed in this thread.

Note that for best performance you need short tubes to the nozzles (low volume to deplete/fill), so valves and sensors are best placed on the machine head. I2C over large cable distances, along with motor driving lines was frowned upon in this group.

_Mark

--
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/dce5f34b-c489-4613-9c98-947f051e0593%40googlegroups.com.

[Airhead Bit]

What is/are ventouri microejectors?

I have a few of the DL200 style differential pressure transducers I purchased to use in a 'Glass Dash' Electronic replacement for 1940 mechanical gauges in an aircraft, combined with radio and transponder the weigh was 32.3 pounds...

I found my vacuum test setup, I need to move the air restriction device to the other side of the valve and add a second 'sensor gauge', the first sensor in the image is something that measures heartbeat. When the I2C sensors show up I'll start coding. The vacuum system won't be going into my existing P&P machine, no room for the tanks. Looking at doing a new P&P with OpenPnP built in using today's technology, SOM stuff, another subject after I do more research..

On Thursday, January 2, 2020 at 9:18:58 AM UTC-7, Marek T. wrote:

Mike, I have one large compressor (not vacuum pump) 5atm in 300litres reservoir tank, and three ventouri microejectors before each of three nozzles. Sensors between microejectors and nozzles.

 

------snip

[Airhead Bit]

From the head to the electronics on my machine is 2 meters, that is the reason for the dI2L and cat 5 flat cable.

PCA9617ATPZ, 3 meters at 1Mhz. https://www.mouser.com/ProductDetail/771-PCA9617ATPZ at qty 10 $0.94 - their on the way. Now to find some miniature cat 5/6/7 cable I can crimp to JST-PH 2mm connectors, I can't crimp HS 1mm pins. Just found cat 7 cable has each pair wrapped in foil, on that note I am replacing all my head cabling with shielded wire, just seems right.

To unsubscribe from this group and stop receiving emails from it, send an email to ope...@googlegroups.com.

[Mike M.]

Yes Mark my SMCs are only 10-15cm from nozzles, and 3cm from solenoid valves (all on head) + non return valve and line to the vacuum pump abt 2-2.5m with vacuum storage tank..
Vacuum pump is activated by mechanical adjustable switch /pressure valve and maintained at max when pressure drops below pre-set value....

[Dave McGuire]

I've seen that, excellent work. Implementing this was my first
choice, and I will probably end up going that way (or at least something
similar), but I'd like to know what others have done, and I'm curious
about potential solutions from the industrial world.

[Michael Anton]

The parts are discontinued by Digi-Key only, and only in cut tape form, as they still list reels as an active part.  Mouser claims it is a new part, and they have stock, as does Digi-Key.  So, what's the problem?

[my 3DCNCPNP]

I used a MIKROE-3195 Vacuum click board from Digikey (about $40USD) which uses a MPXV6115V sensor and has additional parts for analog and I2C output.

Then Marek added the "Part Size" check stage for the Bottom Vision pipeline. Since I always vision align every part I no longer do vacuum checking (Thank you Marek!!)

[bert shivaan]

My commercial machine did not use vac check at all. Only bottom vision to check if part was there/valid.

On Thu, Jan 2, 2020 at 5:59 PM my 3DCNCPNP <my.3d....@gmail.com> wrote:

I used a MIKROE-3195 Vacuum click board from Digikey (about $40USD) which uses a MPXV6115V sensor and has additional parts for analog and I2C output.

Then Marek added the "Part Size" check stage for the Bottom Vision pipeline. Since I always vision align every part I no longer do vacuum checking (Thank you Marek!!)

--
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/ad2dd160-d1fe-4c9d-b4b0-457f76311d6d%40googlegroups.com.

[Dave McGuire]

On 1/2/20 7:46 PM, bert shivaan wrote:
> My commercial machine did not use vac check at all. Only bottom vision
> to check if part was there/valid.

I thought about that a bit this afternoon. I'm chasing vacuum
checking now because, from the beginning of ordering my LitePlacer kit,
I thought it was a very good idea. But now that I've run about ten
panels through the machine with OpenPnP, bottom vision has handily
caught each and every mis-pick that has occurred. I grab tweezers, pick
up the component, "hand" it to the hovering nozzle, and it goes about
its business...problem solved.

Because I'm anal retentive and my customer is paying quite a lot for
these boards, I do a visual inspection before running a board through
the oven anyway. But the human visual system is really bad at noticing
a missing component in a field of 0603s, and frankly, even as a
dyed-in-the-wool tech guy for 40+ years, I really wouldn't want to be
doing that all day long.

So I guess now I'm wondering if I should even bother with vacuum
checking. The bottom vision just works so damn well that I'm beginning
to think there's little benefit.

Does anyone else with more than my meager few weeks' worth of OpenPnP
experience have any comments on this?

[Marek T.]

It's calculation, if some commercial machine does 50k cph it's impossible that vac check is used there the way Openpn does (waiting for level). Or not uses this at all for small parts.

[bert shivaan]

To me I think if I am going to do 100% bottom vision check, vac check is just some wasted time - unless I can do it faster then getting to the camera and checking.

If I am not checking 100% with vision, then the vac check is necessary to verify part is on nozzle.

On Thu, Jan 2, 2020 at 9:24 PM Marek T. <marek.tw...@gmail.com> wrote:

It's calculation, if some commercial machine does 50k cph it's impossible that vac check is used there the way Openpn does (waiting for level). Or not uses this at all for small parts.

--
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/103fb1a9-1ac9-4235-b94d-da81948ed7cf%40googlegroups.com.

[Jason von Nieda]

For what it's worth, the very modern (and expensive, and fast) PnP I use at work seems to use vacuum checks on every pick. This can be disabled on a placement by placement basis, but the default is on and that's how we use it.

I suspect that part of the reason "real" machines use shop air and vacuum ejectors is because they produce a LOT of vacuum so the delays are very short. It stands to reason that if you have a small vacuum flow it will take longer for the vacuum level in your tubing to stabilize for a good reading than if you have a high vacuum flow.

I've been thinking about performance for these kinds of operations a lot, and I think there is a lot to be learned from relatively simple machines like the CHMT36VA. This machine is "cheap", but for what it does, it's pretty fast. OpenPnP comes nowhere near it's performance. A big part of this is because nearly everything except bottom vision is performed on board, without interaction from the controlling software.

On the CHMT the software basically uploads the job file to the machine and the machine executes it autonomously. This means that it can very easily do things like fire a pick and then monitor the vacuum levels in a tight loop without tying up the controlling software. It's all done on the machine controller. I think there is merit to this because it introduces a real time aspect that is hard to get with a serial port connected controller. This makes a lot of sense for this type of one off machine. The software only needs to know about this one machine, and it can be tailored specifically to that one machine.

Since the start of this project, I have always wanted OpenPnP to work well with "generic" controllers, so that it is highly accessible - but I wonder if it's time to start thinking about a custom controller, or at least firmware, for OpenPnP. Something that has built in cycles specific to PnP, or maybe even something that can handle short programs being uploaded that are executed in response to commands. When I think about the evolution of 3D printers, the firmware took the same route. It started with basic movement, but quickly started to include built in PID loops for temperature control, filament detectors, bed leveling, etc.

As one simple example, instead of this:

Send: Move to XY

Wait: ok

Send: Move Z down

Wait: ok

Send: Turn on vac

Wait: ok

Send: Move Z up

Wait: ok

Send: Read vacuum

... etc... etc... etc...

We could have:

Send: Pick X, Y, Z, expected vacuum level N, retries M

Wait: success or failure

This thread has gone completely off the rails, and I'm sorry for adding to that, but it has certainly brought up a lot of interesting thoughts :)

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BKNHNxnaeq5L7wgo7Ge3Roee8VGpEH_khRMra-DJhAjJdgH7g%40mail.gmail.com.

[Marek T.]

So CHMT uses kind of Cura/Slick3r for Pnp.
Is it the way how your expensive/fast professional machine works?

Btw, using loops for vac_check to "adjust" dwell times dynamically instead of hard programmable dwell times is not any problem. Sending readings the vac actuators in the loop was one of the first mods added to my Openpnp. I thought to do it autonomically in some controller (sending single actuator read command together with expected value and waiting for ok when reached), but it's not giving too much advantages.
I use some spec controller for z position of my pneumatic heads. Have their the position sensors being checked by controller in 1ms periods and answering OK to Openpnp when the position is got (kind of hardware M400 for Z). It could be also done using Openpnp loops but I made it before I thought about any Java changes.

[Jim]

On Friday, January 3, 2020 at 5:40:24 AM UTC+1, Jason von Nieda wrote:

Since the start of this project, I have always wanted OpenPnP to work well with "generic" controllers, so that it is highly accessible

Hi Jason,

I think that is what makes OpenPnP so fantastic - you can build a machine with less money and have a lot of fun.

You do not need super-special expensive hardware / controllers to let OpenPnP pick and place whatever.

Yes, the big disadvantage of the current OpenPnP concept is the achievable speed.

But who wants to spend tens of thousands of dollars on professional motion / vision / head / vacuum / feeder systems, if it can be done with modest means.

I would recommend not to make it too complicated. As mentioned before, the vacuum measuring system is one of those things that are very funny, but in practice hardly bring anything on a self-made machine and only cost valuable time and money.

Jim

[bert shivaan]

I have been thinking about new firmware since finding openPNP a little over a year ago.

Some thoughts (my opinion only)

Jason mentioned one time backlash should be handled by the controller not oPNP - I agree. This is measurable and absolute. controller should do it.

We don't really need CNC firmware to run a pick-n-place machine. - WAY overkill and makes it really hard to add significant number of axis.

We could do things like fire bottom lights when the machine is at some pre-defined position, but do we really save anything here?

If we have the controller monitor the vac level, what happens if it fails?

Personally I do mind the idea of uploading the entire job to the controller, but it really complicates things when problems occur.

There is HUGE HUGE HUGE value in having the controller run the machine when CNC is involved, things must happen without delay of any kind. For PNP this is not as important.

Do we really lose much time with the trivial comms we have going on now? (Maybe we lose up to 10mS per transaction due to USB specs?)

Maybe there is real benifit achieved just by running a few instructions ahead to get rid of the slight comm delay.

On my first build, I used the head from my dead commercial machine. This had me doing things like for a pick command:

move Z

fire down valve

wait finite time for nozzle to reach bottom

fire vac valve

wait finite time for vac to suck up part

turn off down valve

fire up valve

wait finite time for nozzle to retract.

I could have easily made that into a single M-code but the reality is it would not have made things faster. once Z was in position, I could make all that happen in the blink of an eye. So I left it as it were and moved on. My point is some things make sense, some things are just fun but add no value.

IMHO, being able to send :

g145x23.789y14.43z-32.998

wait for ok

with g145 defined in the control to rapid to x,y position and pick the part at z height would be fun, but still take the same precieved time.

As for time delay from VAC reading, this is machine dependent and will not get faster simply because we dropped the oPNP side of it.

[bert shivaan]

My current build will require 8 axis - 4C,2Z,1X,1Y plus 8 valves for vac/blow and light control (likely another 8 output just cuz).

I will likely build this using a MEGA 2560 and a "sheild" I already made.

Is the MEGA my goal choice? -NO

Will the MEGA be the fastest?-NO

Will the MEGA be the quickest time to get my machine running?-YES

I would rather use XMOS - but just starting to learn that and no where near the knowledge needed to program

How about a PIC32? I have a board already built I could use - no still need the shield

Oh Oh Oh, how about ESP32? It has all the resources (pin count) and is fast and cheap!! Nope again, unless I learn the Express-IF tool chain, no value added using Arduino or microPY

So the MEGA wins this round. After all the goal is to get a machine running. I still have the same board to get built that I started with last year.

My point is IMHO we don't need something to port openPNP to. It works and does a GREAT job. Are there some thing I wish it did? Of course but there is only so much time in a day.

Controlling a PNP machine from the controller level really is almost trivial as you have it now.

Lets think about things like backlash added to the controller.

As far as VAC check goes, maybe it would be great to send

G142z-32.987

wait for OK

And that would say

move Z to -32.987

turn on VAC

When VAC is high enough retract Z to 0

Send OK to oPNP

And maybe G143z-10.34

that would say:

move z to -10.34

turn off vac

give a little blow if configured to do so

retract to 0

send OK to oPNP

That would be great I think. Maybe I will add that into my control when I do this.

and maybe g142 will really be named p1

and g143 will be p2

[Simon Merrett]

Ref ESP32 is esp32_grbl no use?

[bert shivaan]

GRBL is not custom PNP firmware. It is intended for traditional CNC stuff that requires coordinated motion among multiple axis. PNP requires the Axis complete the move. No regard to the position of X while Y is moving. We do not need to make Arcs or off 45deg lines.

On Fri, Jan 3, 2020 at 7:42 AM Simon Merrett <smerr...@gmail.com> wrote:

Ref ESP32 is esp32_grbl no use?

--
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/b237e881-c39b-41bd-9c41-06f0ed0d807f%40googlegroups.com.

[Airhead Bit]

Something I've been working on:

 

KISS

Using ‘simple’ TMC2160 / TMC5160 and TMC5161 chips driver and TMC API with Cortex-M4 dSPI/422 UART combined with Rotary G-MRMO-031 or KMA36 from TE now driven with Cortex-M4 with dI2C.
STM32MP157x $99 for 4” display and $69 without display: STM32MP157C-DK2

Dual Cortex A7 @650Mhz, Cortex M4 @209Mhz, 6 SPI, 6 I2c, 1GBBaseT, 2 CAN FD, 3 USB, 4 UART, MDIO Slave, RTC, 3D GPU OpenGL, 3 SDMMC, Dual Quad SPI, DDR3/2 External Memory controller, display is DSI 4” with Touch. Read more about the Discovery Kit at STM. NOT the NPX M7 base 1 core Smoothie choice.
Roll your own: BGA448 pin device QTY 1 $18.50 BGA344 pin device QTY 1 $16.54
NOTE: There are other devices below $10 with only 1 core A7+M4 LIKE the NPX smoothie choice and only 1 GB external memory support.
Open Source libraries with Open Source GCC base IDE and compiler.
YOCTO running the Dual A7 with RTOS on the M4 driving the connected TMCxxxx motor drivers.
On the Linear encoders they need to be an ARM M0 controlling the encoder on each axis to provide absolute location using magnetic strips and LDAR, for the TMC516x it appears the KMA36 may be able to drive it directly off the motor.
QT5 Open Source on Yocto appears to be doable on the STM32MP1, TBD, STM ships the STM32MP157C-DK2 with OpenSTLinux, Yocto rebranded.
QT5 and Yocto support Nvidia and i.MX6~8 SoM (System on Module) devices along with SMT32MP1.
On all platforms have OpenPnP running on the A7(s) and modified MODIFIED Smoothieware/Marlin on the Cortex-M4. On the Nvidia and i.MX8 platforms use the CSI camera buss instead of USB 2.0. On the Nvidia Jetson Xavier NX use it for AI training both vision and routing/pick and place strategies.
TBD:
1.    OpenPnP on Yocto
2.    OpenJDK for OpenPnP in place of JDK
3.    QT5 on Yocto
4.    OpenCV on Yocto
5.    OpenPnP migrated to QT5
6.    Smoothieware/Marlin branch with anything not connected to Pick and Place removed. That includes all the code for Curves/Arcs.

I've been working on a goals definition involving a turnkey P&P system suited for the elementary schools in rural areas. Reading your reply to 'Why Java' was informative, today we have QT5 running everywhere with Open Source licensing. With $100 System on Module (SOM) that have 4GB memory, 2/4/6 CPU and GPU running Ubuntu or Yocto (it runs OpenJava) STM, NPX, Nvidia are all focused on the appliance market, Nvidia is dropping a SOM that will do 21 TOPS in March, imaging the ANN that can be built. I envision a machine like the OpenPlacer (with some engineering changes) with an embedded dual A7+M4 and touch screen having the M4 control the machine with the dual A7 doing the commanding. Two or three example projects shipped with the machine and a online video training sessions.  Using TMC516x style drivers and TMC API most of the real-time hassles are resolved so It's a matter of fixing the G Code stuff to not think like a 3D printer, with TMC stuff it is time to move on to the bigger issues like planning placement and feeders, home made machines can only move so fast then improvements need to be found in other areas.
I have some 'stuff' coming to check out the feasibility of embedding a SOM, here is some of the TBD:
 (all the examples need to be tried, trust nothing online)  
1.       OpenPnP on Yocto
2.       OpenJDK for OpenPnP in place of JDK
3.       QT5 on Yocto (found example online)
4.       OpenCV on Yocto (found example online)
5.       OpenPnP migrated to QT5 ?
6.       Smoothieware/Marlin branch with anything not connected to Pick and Place removed. That includes all the code for Curves/Arcs.

STM has a CubeAI that is suppose to generate ANN/CNN for their MCU/MPU products, we'll see.

Basically redefine how we do P&P to match today's technology without the G code baggage.

[Airhead Bit]

Correction: PCA9617 is a voltage translator/buffer,  only, PCA9615 and PCA9616 are dI2C line drivers, the PCA9616 has three two wire channels supporting SDA, SCK, INT back to the MCU, that is what my current design is using: interrupt driven I2C control over differential line drivers to 3 meters. I've found that screw terminal blocks are costly, $6 each for 8 position. Switching to PCB mounted RJ45 connectors with CAT 7 flat shielded cable, $2 for both connectors, master, slave, three two wire pairs plus power = 4 pairs or 8 positions hence the RJ45 designed to be used for transmitting high speed serial data. Not as handy was 1GBaseT Ethernet but a lot cheaper.

[ma...@makr.zone]

Hi Jason

I strongly agree with Jim that OpenPnP is so fantastic exactly because it supports all kinds of controllers, hardware etc. It would be a huge loss to change that for whatever reason.

I'm not so convinced that "the big disadvantage of the current OpenPnP concept is the achievable speed". There is much potential inside OpenPNP aside from drastic hardware solutions.

In a purely professional approach, in order to eliminate speculation and guesswork, the first step would have to be to profile OpenPNP+controller (not so easy in combination) and record where time is really spent. It would have to be evaluated on many machines. Timing videos, where both the OpenPNP screen and the machine are visible, would be the simplest approach to that. 

But because most of us have another "profession", really, let's go back to speculation and guesswork ;-)

My speculation and guesswork goes here:

1. For multi-nozzle machines the JobPlanner alone has a huge potential. We discussed some of that here. 
2. Eliminiate M400 from (almost) all commands. Let the controller queue up the motion commands and let it optimize the motion planning including motion blending etc. (watch the video to see the potential). Most (USB/MCU/CPU) communications delays will be hidden by pipelining. Those remaining will be negligible on top of the motion time.
   
3. Obviously vision has to wait for motion to complete before acting on a camera frame, but instead of waiting for the M400 "ok", use LED strobing by the same controller that does the relavant motion and use it for camera capture motion sync. If the frame is bright on the last scanlines (add a tiny reflector to make sure), that's literally the first frame you want. This hides one half of all the (Camera/Codec/USB/driver stack/etc.) communications delays. With some (optional) "speculative exection" of the following motion command (usually the move to safe Z), you can even hide the second half. If the vision fails, yes, you need to move back down in Z but if this is rare enough (e.g. for the bulk of smaller parts), it would speed up things considerably. This would be easy to add in OpenPNP (I worked on that code).
   
4. Also obviously you need to use M400 before the vacuum checks but again don't wait for the M400 "ok". Instead check the vacuum reading result asynchronously, as soon as it comes back from the controller (a bit like the M114 response is already captured asynchronously today). In all practical cases this will surely come back long before the motion to the next (relevant) location has completed. If not, wait only in this rare case. This is effectively a "in flight" vacuum check and you can still discard the part after this motion. Again this would be quite easy to add in OpenPNP, the Driver would just have to be primed with the relevant vacuum range to check and record and retain the success state for to the next JobProcessor step to evaluate (again, I worked on that code :-)).

For all (or most) of that you don't need a special controller. But the controller would for most of the time act on its own, autonomously, off the queue, as fast as it can. In my view that is all you can expect anyway.

To my knowledge, true motion blending is only supported by LinuxCNC, but having this changed in OpenPNP would be a great incentive to add some sort of it to Smoothieware.

Just my 2 cents,

_Mark

[Dave B.]

Disclaimer: I am learning OpenPNP and CNC stuff.  I decided to follow(ish) the recommendations on the wiki for what to build. Feel free to ignore my thoughts as I am still in the process of getting a machine working.  I realize that even bad experience can be worth a lot more than good ideas.  I don't have the experience with OpenPNP to back up what I'm saying (yet).

With that being said...

If the main thing slowing down fast machines is the latency and verbosity of communication between the host PC and motion controller, extending the motion control firmware to allow "compound commands" seems like a good solution.  OpenPNP can work as it does currently to support everyone/everything.  OpenPNP also allows using an abbreviated command set that offloads more for controllers that support it, where extended commands replace a group of fast-executing commands with one compound one.  Things can continue at the pace they've always continued or things can move faster.

I do mostly automotive embedded stuff, mostly hardware some firmware. The crazy bundle of wires for steppers, cameras, etc. etc. etc. that has to neatly travel around at high speed was one of the first things that blew my mind when getting serious about OpenPNP.  Before I decided to just build something the "conventional" way (i.e. smoothieboard and a ton of wires moving around) I had the thought of using automotive ethernet to cut down on the signalling to the head.  It's high enough bandwidth (100mbit) to move camera data, it's low enough latency to be a step up from USB.  It's a single unshielded twisted pair on the physical layer.  It's designed for reliable operation in noisy environments.  It's also dirt cheap because of the volume of use in the automotive sector.  Strikes me as a damn good fit.  Put C axis control (and Z) on a small, lightweight control board with automotive ethernet.  Run a twisted pair for control and power ground.  Bye bye massive bundle of wiring.  Requires coordination of motion control firmware, hardware, design, OPenPNP.  Non trvial.  But potentially a big step forward?

https://en.wikipedia.org/wiki/BroadR-Reach 

http://www.ti.com/lit/wp/szzy009/szzy009.pdf 

-Dave

--
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/bba7e917-5327-4ce2-9062-ffdc7918b5ce%40googlegroups.com.

[John Plocher]

On Fri, Jan 3, 2020 at 10:32 PM Dave B. <blu...@gmail.com> wrote:

If the main thing slowing down fast machines is the latency and verbosity of communication between the host PC and motion controller,

It isn't, really...

Even at stupid slow serial/USB timings, the physics of it all (inexpensive construction, camera shutters @20-30 frames per second, F=MA stepper motor velocities, vibration, dwell times to keep components from bouncing all over the place) conspire to be even slower :-)  

IMO, there is some premature optimization going on in these discussions without a lot of measured facts backing them up - people propose faster cameras, faster steppers, faster image pipelines, faster s-curve accelerations, etc etc etc, yet we're just now starting to understand the impact of the placement algorithms on the CPH speeds :-) 

  -John

[Airhead Bit]

What I noticed when I imported my first P&P was my PCB layout software was/is brain dead: It grouped parts by Refdes meaning one part could be at 2,2 and the next at 200,200 because the Refdes R1, R2. With a single head maters not, two heads or more it matters. Best let this thread go back to Regex woes!

[Duncan Ellison]

OP here - WOW, talk about thread drift :-)

Just thought I'd come back to report where I got to with this.  Thanks to Jason's help I ended up with 

ok T:(?<Value>-?\d?\d?\d?\.\d?) \/\d\.\d @0

Which seems to work fine on a string of :

2020-01-06 10:20:02.748 GcodeDriver TRACE: [serial://COM3] << ok T:-99.4 /0.0 @0

For what it's worth, I'm using Panasonic DP101 sensors tapped into the Vacuum lines (not at the head) and they seem to work fine and respond very quickly to part on / part off. (see photo).

My mistake was getting DP101 and not DP-101A (now on order) which have the analogue output.  They were not too spendy on AliExpress - $35 each.  Plus you get a really nice digital display so you can see the pressures.

I also modified the thermistor inputs on my smoothieboard to take raw analogue without damaging the input pin on the uP.  Basically just used the hot air pencil to remove the four capacitors and the one resistor network.  (Hint: use Kapton tape to prevent blowing other items off the board). It seems to be working OK.

Duncan

 

On Tuesday, 31 December 2019 14:09:23 UTC, Duncan Ellison wrote:

Hi Guys,

What have I not understood about reading the vacuum using regex?  I've tried to follow the tutorial, but can't seem to return a value.

I have Head 1 - Nozzle 1 - ACTUATOR_READ_COMMAND set to M803

I have Head 1 - Nozzle 1 -  ACTUATOR_READ_REGEX set to (?<Value>-?\d.\d+)

Actuating H1N1_VAC > Read Value successfully issues the M803 (see log below), the Smoothie answers with  ok T:inf /0.0 @0 but the value returned seems to always null.

2019-12-31 14:03:27.372 GcodeDriver DEBUG: sendCommand(M830, 10000)...

2019-12-31 14:03:27.373 GcodeDriver TRACE: [serial://COM3] >> M830

2019-12-31 14:03:27.374 GcodeDriver TRACE: [serial://COM3] << ok T:inf /0.0 @0

2019-12-31 14:03:27.375 GcodeDriver DEBUG: sendCommand(serial://COM3 M830, 10000) => [ok T:inf /0.0 @0]

2019-12-31 14:03:27.375 ReferenceActuator DEBUG: N1_VAC.read(): null

I tested the regex with an online tester and it matches 0.0.

BTW, I know that I should really be reading the part that says 'inf' which presumably means 'infinite' as I haven't got the actual sensor hooked in yet.  I'm assuming also that null really means null and not 0.0

I just got two very nice Panasonic sensors today, but found out that they only switch rather than deliver an analogue representation of the vacuum, so I'm going to have to use 0V or 5V from the NPN driver as the part on / part off sense :-(

Duncan

 

[Simon Merrett]

@cncmachineguy May I ask what custom PNP firmware on your ATMEGA2560 allows you to get up and running quickly? Would be interesting to know.

The fact that grbl isn't custom PNP firmware doesn't automatically make it unsuitable for such purposes, unless you can explain how. Your correct statement that PNP doesn't need the same degree of axis-coordinated motion as e.g. CNC routers/lasers doesn't prove that grbl is unsuitable. For example, if the path planner in grbl can handle curves, jerk, acceleration, velocity, why shouldn't it do a good job with simple straight line commands from PNP gcode? If the distances are large, rather than broken up into smaller segments as they would likely be from a grbl CAM postprocessor, wouldn't the grbl path planner just work to its maximum speed, acceleration and jerk over that move? I really am a novice at all this and your nickname suggests you are not, but from your reply below I'm failing to see an argument against esp32_grbl.

Simon 

On Friday, 3 January 2020 13:11:34 UTC, cncmachineguy wrote:

GRBL is not custom PNP firmware. It is intended for traditional CNC stuff that requires coordinated motion among multiple axis. PNP requires the Axis complete the move. No regard to the position of X while Y is moving. We do not need to make Arcs or off 45deg lines.

On Fri, Jan 3, 2020 at 7:42 AM Simon Merrett <smerr...@gmail.com> wrote:

Ref ESP32 is esp32_grbl no use?

--
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 ope...@googlegroups.com.

[Mike M.]

Nice find Duncan - looking great.

Mike

[bert shivaan]

Let me go backwards here:

I have been a machinist for 30 years. started out manual, all CNC now. I have also been building industrial machines for 20 years, from 20,000 pound 3 axis motion bases to 6 axis foam cutters.

As for GRBL, it is a wonderful program. Currently I am using a modified version to control my PNP. The limit is number of axis. There is code on openPNP giving GRBL 4 axis. I started with that and added Mcodes so I could control 24 valves. That all works great. It is very suitable!!

BUT

The thread you refer to is talking about custom PNP controller. I was commenting that I will be doing something for myself along that line soon. I will need 8 axis to start off, could go to 14. This is very easy to do when not trying to coordinate all of them.

I was quickly listing the choices with quick thoughts as to why/why not use them in my opinion.

That is where the ESP32 came up. I am in NO way a good enough coder to alter GRBL or any other to have 8 axis, much less 14. I am however good enough to write code from scratch to control that many steppers including accel/decel.

Yes we can use subdrivers to increase the number, but there really is no need to do that.

And finally,

I have no custom firmware yet. That said it would only take about an hour or 3 to be up and running using GRBL with 4 axis. If that is all you need to do. The tricky part comes in when you need more inputs or outputs. Then the custom stuff starts to happen. If you can live with using coolant control to provide outputs and a few inputs, then GRBL works out of the box.

Please ask away any questions I have prompted :)

Bert

[E O]

klipper might be worth a look. it divides the code into a low-level layer running on a MCU to do step gen and other IO, and high level code (in Python) doing motion planning, gcode interpretation etc.

because of this, the MCU code is pretty simple (and has already been ported to many chips), while the high level code is also quite a bit more approachable. and configuration (ie adding an axis) is just done by editing a text file.

[bert shivaan]

I will take a look, thanks!!

--
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/30c02396-f251-4200-a965-2285e3151056%40googlegroups.com.

[Mike M.]

Duncan

See here how fast this vacuum sensors do the job!

https://youtu.be/m9YVruOjq9U

Mike

On Monday, 6 January 2020 11:51:27 UTC+1, Duncan Ellison wrote:

[Jim]

Cool video, I think if speed plays a big role, there is no way around mounting the sensors directly on the manifold of the head to keep the air volume as low as possible.

On Thursday, January 9, 2020 at 10:30:36 AM UTC+1, Mike M. wrote:

https://youtu.be/m9YVruOjq9U

Cool video.
I think if speed plays a big role, there is no way around mounting the sensors directly on the manifold of the head to keep the air volume as low as possible.

[Duncan Ellison]

I'll see how it goes when I get placing in anger, speed isn't really my absolute goal, but accuracy is.

Nice to see they use the same sensors as me.  They also have them programmed in the same way as I do so they go green when the sense enough vacuum, which does look quite cool.

Duncan  

[Airhead Bit]

I was setting up to do the coding for the 4 Gcode controllers I have while waiting on the parts for the PCB when I wondered how OpenPnP would deal with accessing the values. Discovered 'subdrivers', point to a port and give it the regex  values needed. besides the fact of having to add a second RJ45 connector to the PCB and having to program all the Gcode controllers was a little more then I signed up for.

New board: STM32G431 with USB port will control the sensor and offer I2c and SPI connectors. The USB shielded cable is a lot less money then the 4 pair dI2C cable and the micro AB on the sensor is 1/10 the price of the RJ45 and a lot smaller.

E O with the Klipper post sealed the deal.

This is a Honeywell sensor I use in Drones for airspeed, at $39 each a bit pricey, the new sensor is a lot smaller.