Smoothie on STM32/CHMT Discussion

[Matt Baker]

Splitting the thread to organize the discussion.

Github: https://github.com/mattthebaker/Smoothieware-CHMT/tree/chmt

[Matt Baker]

I received my Nucleo-F207ZG dev board and got to hacking a bit.

Swapping the LQFP-144 was trickier than expected, I'm not sure I would generally recommend it unless you have some experience, but it would be good practice if you intend to rework the charmhigh controller.  I had to use low temp bismuth solder paste.  Had to remove one option resistor and short three solder bridges.

The dev board powered up on the first try.  I reflashed the ST-Link with J-Link because I'm familiar with their tools.  Segger Ozone (debugger) loaded, flashed, and debugged right away using the smoothie build output.

I worked through a large number of bring up issues, but there are still some more to go.

Now, I have smoothie minimally running on STM32F4 at max clock speed, UART responding and taking commands, some LEDs flashing, compile-in config file loading, and the slow ticker running.  Once the axis config is added, I think that it will execute G Code as expected -- though I expect my step generator port may need a touch up.

Need to continue working through peripherals and functionality but I feel its 75% of the way to a functioning build.

[Dominic Clifton]

excellent work, got a photo or two to share?

[Ferdinand Keil]

If you don't care about the chip you're removing I find cutting away the pins the easiest solution for high pin-count LQFP packages. You can use an xacto knife with a fresh blade or a rotary tool with a cutting disk (think Dremel). Make sure you cut right at the edge of the package and do not bend the pins too much as this risks shearing off pads from the PCB. The cutting disk is very gentle to the pins in my experience, but you need a steady hand to not hit the PCB.

After all the pins have been cut you can remove lift out the package, flux the pins and gently shove them from the pads using a wide tip in your iron. After you have wicked away the left-over solder you're good to go.

[Arthur Wolf]

If you have access to one, the neatest solution by far is to just use your CNC mill/router. Done it only once but it was extremely satisfying, and I was surprised how fast it was to set-up/do.

--
You received this message because you are subscribed to the Google Groups "Desktop Pick and Place" group.
To unsubscribe from this group and stop receiving emails from it, send an email to desktop-pick-and-...@googlegroups.com.
To post to this group, send email to desktop-pic...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/desktop-pick-and-place/d6893e44-913f-45f0-a404-fffc74d533d3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Courage et bonne humeur.

[Gregor Maček]

Ah come on!!! You are torturing my eyes reading such propositions ... What is wrong with hot air, which can remove any IC without any damage on either PCB or chip itself???

The main trick is not to heat IC with small tip and from small distance, but rather use wide hotair tip, higher air flow and higher temperature. This way, heatinf gun can be further away and heats all chip simoultanously.

Regards, G

--

[Matt Baker]

Resolved another issue I introduced with mbed hooks for STM32, here is the dev board generating step pulses.  Cranked the speed up in the config to show that it is generating steps at 100kHz.  I can't get the pulse width much below 2us though.

[Dominic Clifton]

lol Gregor, I was thinking the same.

To view this discussion on the web visit https://groups.google.com/d/msgid/desktop-pick-and-place/CAM8aekVYmBpKLDD4PrO%2BSrq-V2ktEF1jqVWAjsOOM-gm%2BcG_BA%40mail.gmail.com.

[Matt Baker]

My rework problem must certainly have been the nozzle size.  Even with the bismuth (low temp) paste added it wasn't easy to flow the entire chip.  Will try a larger one for next round.

I now consider the port of smoothieware to STM32 more or less done.  I rewrote and tested the ADC back end which was the last big remaining piece.  Subsystems interacting with ported pieces all pass basic tests: digital in/out, pwm, hwpwm, adc in (thermistor), motor drive (steps, dir, en), timers, watchdog, and soft kill switch.

We still need a config file, but it is ready to be loaded up on a machine and brought up.

[Venelin Efremov]

Trying to compile smoothie/STM32:

make[3]: *** No rule to make target 'vendor/STM/cmsis/STM32F407xG/GCC_ARM/STM32F407xG.ld', needed by '../drop/STM32F407xG/GCC_ARM/STM32F407xG.ld'.  Stop.

--

You received this message because you are subscribed to the Google Groups "Desktop Pick and Place" group.
To unsubscribe from this group and stop receiving emails from it, send an email to desktop-pick-and-...@googlegroups.com.
To post to this group, send email to desktop-pic...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/desktop-pick-and-place/98f17b41-3edf-4e63-a64d-3cff5294af7c%40googlegroups.com.

[Venelin Efremov]

Never mind. Figured it out. I’ll send a PR shortly.

[Matt Baker]

Ok, might be a platform specific issue? I just repeated a clean build and didn't see anything.

If it wasn't clear on github, chmt and nucleo-144 are the primary branches.  chmt is the base, and nucleo-144 has changes specific to my dev board.  Comparing the two will highlight what might need changing for another board.  nucleo-144 also has the config copied over from openpnp-openbuilds as a starting point.  src/config.default gets compiled into the firmware to replace the sd card config file.

Matt

[Venelin Efremov]

Compiling on Linux, there was an issue with the file name, because the filesystem is case sensitive. I sent a PR with a fix.

[Dominic Clifton]

Hi all,

Just thought I'd share some information regarding the motor configuration on the CHMT48VB I found in the menus on my machine today.

Name, Pulse (PPMM), Speed (rpm), Accel/AccelA(Rps2)

XYA Motor,1600,700,70

Z Motor, 1600,400,40

I figured it might be useful to know and also to compare to the CHMT36VA.

[Matt Baker]

The port was already generating functional signals, but I found a stepper board that fits the nucleo-144 to spin some real motors.  Just needed to edit a few config lines to drive the right pins, and send some simple gcode e.g. G0 X1000 Y100 Z10.

https://youtu.be/AxExVDUnpMQ

[Dominic Clifton]

Nice work Matt, I'm very impressed with your progress!

I've been busy coding in Groovy on PnPConvert so I can use the exisiting CharmHigh firmware, but maybe soon I can ditch that and use OpenPnP :)

Dominic

--
You received this message because you are subscribed to the Google Groups "Desktop Pick and Place" group.
To unsubscribe from this group and stop receiving emails from it, send an email to desktop-pick-and-...@googlegroups.com.
To post to this group, send email to desktop-pic...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/desktop-pick-and-place/9f1692e5-2e0f-49b2-9aec-0068c1010c34%40googlegroups.com.

[Matt Baker]

Nothing much to report on the smoothie port itself, however I have gotten approval to acquire a machine, probably a 48VB. Big Crab Coming.

Will probe out the remaining micro connections, the step signaling, and some of the system connections when I get it.  Will be able to try the bootloader dump code.

Not sure what I will do about the cameras if I choose the 48VB, I guess I'll make a breakout board and get some USB capture cards.  Replacing cameras with higher res and USB native would probably be better for permanent openpnp conversion but being able to revert is desirable until its fully reversed and operational.

[Erich Styger]

I've gotten approval for a CHMT36VA, ordered yesterday from Robotdigg. I'll try to get my hands on the Smoothie firmware for it too, if I can be of any help.

I'll probably start with the STM32F407 discovery board and will see how it goes.

[Matt Baker]

Nice!  Code is ported, still need a config file.  Most of the pins on the controller are mapped to PCBA connectors except the motor interface -- I posted on the controller thread.  Still need to map system connections and their controller ports.  Would recommend starting with the E-Stop if you load the smoothie port.

I posted some dump code to extract the charmhigh bootloader and fuse bytes.  Still need to patch that and load with charmhighs bootloader.  Until we get their bootloader flashing smoothie will be non-reversible.

Discovery board is a good start and it looks like it has the 8Mhz crystal already.

[Erich Styger]

Do we know if we will be able to reflash the STM on the original board? I know that it should not only be possible to prevent readout of the firmware (what probably has been done), but as well to erase it?

If that is the case, the only way would be to de-solder the chip which is doable with the right equipment, but for sure not something for everyone.

Erich

[Matt Baker]

Stm32 can definitely lock out debug including erase permanently. We aren’t positive on whether it is active or not. I believe Colin said he thought it enumerated which would mean it is not erase locked but no one confirmed. The “encryption” used by charm high bootloader was reversed enough that we can already resign their bin. That provides alternate path once we’re stable.

When I was reading the erase lock section in the datasheet there seemed like quite a few reasons not to do it so fingers crossed.

Board has a header so will be a quick check.

[Matt Baker]

I confirmed that the stm32 debug interface is read locked, but not erase locked.

I attempted to determine the step minimum pulse width, however the controller firmware generates steps at 50% duty cycle not with short pulses. I didn’t want to try long fast seeks with the top off. It will be easier to just push it until it skips once custom firmware is running.

[Erich Styger]

My machine arrived this week, so did the STM32 board. But I did not had really time to get my hands on it (yet). I made some trials with the original firmware, and the machine operates at least to that level.

I did not open the machine yet, I think one step would be to find out which pins are responsible for what? Or is this information already available somewhere?

[Colin O'Flynn]

There is some partial pinout - I had posted scans of front/back of board such tracing was possible (https://raw.githubusercontent.com/sparkfunX/Desktop-PickAndPlace-CHMT36VA/master/Reverse-Engineering/main_pcb/raw_images/main_pcb_layered.jpg), BUT the stepper driver connections are missing...

I'm not sure if anyone was ever able to get a spare controller board?

--

Colin O’Flynn

C.T.O., NewAE Technology Inc.

(cell) 902 440 1458

--

You received this message because you are subscribed to the Google Groups "Desktop Pick and Place" group.
To unsubscribe from this group and stop receiving emails from it, send an email to desktop-pick-and-...@googlegroups.com.
To post to this group, send email to desktop-pic...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/desktop-pick-and-place/c664c133-353d-48e9-835f-cafd117143fd%40googlegroups.com.

[Erich Styger]

hanks for the scans! I'm not aware of anyone who was able to get a spare controller board.

Just a thought: my understanding is that Jason was able to get everything handled with OpenPnP, with the exception of the nozzle rotation. I was thinking I could maybe disconnect the nozzle motors and make the C1 and C2 rotation available with an extra smoothie board. Or any other missing access to the hardware. Reprogramming the original STM32 would be a better hardware option, but if this fails or will be too hard, using a Smoothie instead might be an option too`?

On Sunday, 16 December 2018 14:14:23 UTC+1, Colin O'Flynn wrote:

There is some partial pinout - I had posted scans of front/back of board such tracing was possible (https://raw.githubusercontent.com/sparkfunX/Desktop-PickAndPlace-CHMT36VA/master/Reverse-Engineering/main_pcb/raw_images/main_pcb_layered.jpg), BUT the stepper driver connections are missing...

I'm not sure if anyone was ever able to get a spare controller board?

--

Colin O’Flynn

C.T.O., NewAE Technology Inc.

(cell) 902 440 1458

On Sun, Dec 16, 2018 at 3:54 AM Erich Styger <stone...@gmail.com> wrote:

My machine arrived this week, so did the STM32 board. But I did not had really time to get my hands on it (yet). I made some trials with the original firmware, and the machine operates at least to that level.

I did not open the machine yet, I think one step would be to find out which pins are responsible for what? Or is this information already available somewhere?

On Sunday, 16 December 2018 08:02:41 UTC+1, Matt Baker wrote:

I confirmed that the stm32 debug interface is read locked, but not erase locked.

I attempted to determine the step minimum pulse width, however the controller firmware generates steps at 50% duty cycle not with short pulses. I didn’t want to try long fast seeks with the top off. It will be easier to just push it until it skips once custom firmware is running.

On Sun, Dec 2, 2018 at 11:29 PM Matt Baker <baker....@gmail.com> wrote:

Stm32 can definitely lock out debug including erase permanently. We aren’t positive on whether it is active or not. I believe Colin said he thought it enumerated which would mean it is not erase locked but no one confirmed. The “encryption” used by charm high bootloader was reversed enough that we can already resign their bin. That provides alternate path once we’re stable.

When I was reading the erase lock section in the datasheet there seemed like quite a few reasons not to do it so fingers crossed.

Board has a header so will be a quick check.

--
You received this message because you are subscribed to the Google Groups "Desktop Pick and Place" group.

To unsubscribe from this group and stop receiving emails from it, send an email to desktop-pick-and-place+unsub...@googlegroups.com.

[Matt Baker]

I had mapped the controller pins to controller headers using colin's images and posted to the other thread.  I traced the unknown system connections and added them into a new column.  Motor pins still haven't been confirmed, I plan to discover which is which by trial and error.  Assuming that the gui matches the silkscreens on head pcbs the head 1/2 items should be correct.  Vacuum vs blower is TBD (my machine the wires are spliced inside of some heatshrink.  Just trivial stuff left to confirm 100%.

Time to try and dump the firmware.  I think I have an extra step or two in figuring out the update process for the 48VB.

Maybe need to clean up the sheet and decide if csv is the best format to pull request the sparkfun repo.

[Matt Baker]

Erich, can you check if your USB stick came with a firmware bin file on it?  Some of the other members received disks with a firmware bin, though it seems that the build doesn't match their serial numbers.  You have the newest CHMT36 so maybe we can get the most recent build.

I think I may proceed by chip swapping or trying to buy a second board from CHMT until I am certain we have a firmware bin new enough I can restore my machine if necessary.

[Erich Styger]

Matt,

I have to check this tomorrow and will report here what is on the stick.

I had to be very careful with the content on it and did not execute anything, as my Windows 10 virus scanner reported several files on it infected by a worm (outsch!).

So what I have used to operate the maschine is the host software available from the SparcFun GitHub site.

[Erich Styger]

This is what came on the memory stick:

This is what is in the 1341 subfolder:

I don't see any .bin files. But there is a worm on the stick:

[Matt Baker]

Thanks for checking Erich.  The worm is certainly concerning.

The 48VB USB included LICENSE.smt and sys_params.smt, so a 48VB could possibly be converted to an external PC with charmhigh software -- though there would be a complication with the cameras for sure.  Or maybe those files are not even necessary to use the 36VA software if you skipped using the USB stick.

[Erich Styger]

I'm using the V3615 from https://github.com/sparkfunX/Desktop-PickAndPlace-CHMT36VA/tree/master/Software with the license file which was on the stick and that worked fine for me.

Still exploring the capabilities of the machine. And I have removed the front panel/plate so I can access the controller board easily.

[Matt Baker]

Alright, I'm done bringing up the smoothie port on the charmhigh controller.  All features functional excluding XY axis encoders, and the right side cover tape peeler.  The latter requires 7 motors which isn't supported by smoothie -- though it doesn't look too difficult to add, but would require mods to some core code that would need a bit more verification than I'm prepared for.

All of the mechanics are sufficiently reversed that the motion configurations have the right distances.  I'm not sure if we're losing a microstep to the potential double edged stepping or not, but motion seems fine with the short pulses smoothie generates.

Everything is present that is necessary to start configuring and using OpenPNP with it to run jobs.  

I have only done unit test style verification of all the features, the firmware needs to be put through some long duration testing to make sure its stable.  Besides that, I want to sync with Jason and standardize the specific GCODEs we're using to control the peripherals.  Once these two things are complete we would be near something that could be called a release.

On a 36VA, the only thing that should be necessary is adjusting the machine size.

I haven't started configuring OpenPNP yet, but will be working that and getting my camera board wired up next.

If I get a chance I'll make a video demonstrating all the features.

Matt

[Jason von Nieda]

Awesome work Matt! This is great news!

Do I understand correctly that to use this we need to blow away the bootloader as well as the application? And presumably you are programming this over SWD?

Jason

--

You received this message because you are subscribed to the Google Groups "Desktop Pick and Place" group.

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

To post to this group, send email to desktop-pic...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/desktop-pick-and-place/50c0f880-41ea-41c5-8cf8-89c061593f0d%40googlegroups.com.

[Matt Baker]

Thanks Jason!

For now, yes we need to blow away the bootloader and application -- flash read protection is enabled and the only way to undo it is a full chip erase.  I'm using SWD with a J-Link, but any STM32 dev kit with the ST-Link would work too for mainstream users ($10.33 on mouser).  I haven't looked into a bootloader for STM32 yet so subsequent firmware changes will also require SWD.  I think for now I plan to embed an ST-Link into my machine when I close it up. I want to have the option of interactive debugging available.

As far as the charmhigh bootloader, if it can be reversed enough we might some day be able to load smoothie back and forth.  Although, in the other thread, I not very cautiously messed with it and bricked their firmware almost immediately trying to update.

It would be good to sync up on standard gcodes for the peripherals if it matters at all.  I'll be digging into your charmhigh openpnp config and working on getting the machine setup over the next week.  A lot of the system config (feeders, camera coords, etc) should work with smoothie and your native driver.  My machine is 48vb, but my buyer convinced kimi to sell us the USB camera switch so my setup will be very similar.

Matt

[Rene Rettkowski]

I follow the discussion and your work with great interest. I got a chmt36va 3 weeks ago and I am very interested in using openpnp with the machine. You are doing a great job and I think that it is a great solution! When I have my next jobs done i would be very happy to test the firmware.
Many regards Rene

[Matt Baker]

I reversed and tested the motor configuration for the right side tape peeler in the 48vb branch.  The code changes to enable 7 axis were more trivial than I expected from my initial audit.  I think the real hazard is in timing and memory changes from the larger data structures.  We're running fairly low microstepping (1/8) so I think we should be pretty safe, but the machine will need to be put through some cycles before we can be certain.

I upped the config defaults for speed and acceleration.  They still need a bit more tuning, but I need to bolt down my top plate first.

Working on openpnp config and first placement now.  I'll post a combined openpnp+smoothie video soon.

[Matt Baker]

First run of OpenPNP+Smoothie+CHM-T48VB: https://youtu.be/EJm0tj4YsrE

This video shows functional drag feeder, fiducial finding, vacuum sensing, and some 0603 placements at various angles.  Need to take a look at the bottom vision next, but the accuracy on the 0603s is really good without it.

[black...@blackboxembedded.com]

Dude!

[Jason von Nieda]

Amazing work Matt! This is super exciting!

Jason

On Tue, Jan 22, 2019 at 6:45 PM Matt Baker <baker....@gmail.com> wrote:

First run of OpenPNP+Smoothie+CHM-T48VB: https://youtu.be/EJm0tj4YsrE

This video shows functional drag feeder, fiducial finding, vacuum sensing, and some 0603 placements at various angles.  Need to take a look at the bottom vision next, but the accuracy on the 0603s is really good without it.

--

You received this message because you are subscribed to the Google Groups "Desktop Pick and Place" group.
To unsubscribe from this group and stop receiving emails from it, send an email to desktop-pick-and-...@googlegroups.com.
To post to this group, send email to desktop-pic...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/desktop-pick-and-place/7aac42b3-c908-4169-a294-6c29ba64f074%40googlegroups.com.

[Andreas Axelsson]

Wow!! This is so cool!

Is there any changes to the hardware or have you just chip-erased the STM32F4 and put your Smoothie based FW on it? What is the differences between the 48VB and the 36VA that I have that needs to be considered trying to bring this up on the 36VA?

Best regards,

Andreas

[Matt Baker]

Thanks, only a handful of components were wasted in the making of this video :).

For the 36VA, no hardware changes are necessary.  For 48VB a custom cable needs to be made for the RS422 interface as well as adding a USB-RS422 converter, and the cameras need some custom work (I can advise but I had charmhigh send me the mux board from the 36VA).

Regarding firmware for 36VA, the only thing I believe needs to be changed is the machine size definitions and soft endstop configuration, to make sure the machine cannot be commanded out of the work area. Its a trivial change but someone needs to confirm the machine extents. This is also assuming charmhigh didn't swap any cables around on that model.  You can just chip erase the STM32F4 and load the smoothie port, but there will be no going back to charmhigh as far as we know.  You'll need a SWD or JTAG debugger that can work with STM32.

Supporting the camera switching to use both bottom and top vision still needs a little enabling in openpnp.

I still have quite a few odds and ends to configure in openpnp but hopefully we can have a somewhat official complete config file for 36VA/48VB at some point.

Matt

[black...@blackboxembedded.com]

Hey Matt

Great work. I would needle through all the diff threads and piece this thing together but don't have time and cant have the machine down for an extended period. I need a turnkey solution to replace the funky charmhigh drivers/sw. If you could post a complete follow up on what exactly is needed materials/sw to get this machine (36VA) running wo the charmhigh drivers/SW I'd be willing to donate $100 to the cause.

Thanks

Wayne

black...@blackboxembedded.com

[Matt Baker]

Thanks Wayne. There will be a complete follow up with instructions at some point, but we're still very much on the cutting edge and not quite ready to plug and play.  At that time it will only require an ST-Link or J-Link or similar for the 36VA model.

Jason has done a lot more work (developing OpenPNP) towards making this possible and already has a gofundme setup (https://www.gofundme.com/help-openpnp-grow) if you want to help drive this forward.

Best,

Matt

[black...@blackboxembedded.com]

Done, I see you on there as a donor as well ;) thanks for your work.

[Matt Baker]

I disabled the ADC oversampling, because we don't need the extra resolution, but we want the ADC to respond faster for vacuum sensing than a 3D printer temp sensor.  This made vacuum sensing with the drag feeder work better for me, though we may need to tune again later.

I also pre-built and pushed up a binary, since we are stable enough to run the machine and I expect some people besides me may be trying it out soon.  This should work on either machine model, but it won't limit max travel on the 36VA.  Configuration changes require compilation so re-building may be required until we're stable.

For now, be cautious and bring up the machine like you would a new CNC, at least until we confirm there are no major wiring differences between 36VA/48VB: make sure the endstops are triggering, that the head moves in the correct direction. Be ready to kill power via the switch, the e-stop should work but it is software not hardware.

[Arthur Wolf]

If you are going to be significantly modifying the ADC stuff, it could make sense to make a new module that does just that. Either just a module that causes a given M-code to report a 0-1024 or 0-3.3v value, or a module with different sensors ( the way temperaturecontrol has thermistor but also thermocouple etc ) where one sensor would be the "raw" values as just mentionned but you'd also have another sensor that would report the actual vacuum in the right units ( after you configure the right ratio in config ).

You don't *need* this, but it'd be a cool feature for Smoothie in general, and if it gets integrated into the mainstream Smoothie, then you'd likely get contributions/improvements there that you could then merge back into your port.

Something to think about.

As always awesome work ! ( and thanks for adding to the wiki )

--

You received this message because you are subscribed to the Google Groups "Desktop Pick and Place" group.
To unsubscribe from this group and stop receiving emails from it, send an email to desktop-pick-and-...@googlegroups.com.
To post to this group, send email to desktop-pic...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/desktop-pick-and-place/d88fd717-ad6b-429f-9611-1be7b8263572%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Courage et bonne humeur.

[Matt Baker]

Hey Arthur,

I may look into doing that. In the past people have just defined the vacuum sense as a thermistor for openpnp, but getting rid of whatever nonlinearity that introduces would make configuring vacuum thresholds better.  Raw voltage or ADC ratio would be a good step -- I'm not really certain yet if the sensor is ratiometric or absolute.  If we can identify the sensors they used maybe we could do native pressure output too.  I think generally we just need a threshold good enough tell if there is something on the nozzle or not, it doesn't seem like much precision is required.

This ADC change for now was just a one liner to disable oversampling, which also knocked out an average of the last 4 system ADC reads in the low level ADC read function.  I'm not sure if that was there for noise or stability for the temp sensing, but possibly the average of 4 would have to be moved into the thermistor code.  If I estimated correctly the extra average puts the response time in the neighborhood of 100s of ms.  I understand that the ADC on LPC produced a lot of glitches so I'm not sure how that factored in. This was a quick change and probably not the long term solution.

On the subject of M code outputs, at present is it possible to read an arbitrary digital gpio input using the switch module and an M code, or am I too dense to figure it out? For now I just put the Z head return and pull pin return detectors as Zmin/Zmax so I could get the status with M119.  One of the things I need to figure out for openpnp is how I can use those outputs to prevent unsafe x-y moves.

I learned a couple things doing the port that could be good pull requests, I'll see about packaging them up.  Getting STM32 integrated might be messy unless some new abstractions are added, although Venelin on this list has already done a version of my changes using #defs for platform specific changes. That is against the smoothie ethos I think, so its hard to tell how it stands.

Matt

[Matt Baker]

For anyone wanting to test out the smoothie port, I pushed up my current openpnp machine config.  It is still highly incomplete but it is a starting point.

https://github.com/mattthebaker/openpnp-config-chmt

[Matt Baker]

Sorry for spamming, but be cautious. The park position for 48VB would crash the head on the 36VA, and there may be other hazards...

On Fri, Jan 25, 2019 at 2:23 PM Matt Baker <baker....@gmail.com> wrote:

For anyone wanting to test out the smoothie port, I pushed up my current openpnp machine config.  It is still highly incomplete but it is a starting point.

https://github.com/mattthebaker/openpnp-config-chmt

--
You received this message because you are subscribed to a topic in the Google Groups "Desktop Pick and Place" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/desktop-pick-and-place/C-n9dksqhDQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to desktop-pick-and-...@googlegroups.com.

To post to this group, send email to desktop-pic...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/desktop-pick-and-place/ee96840d-accc-4438-9821-7c9c177830f0%40googlegroups.com.

[Arthur Wolf]

On Fri, Jan 25, 2019 at 11:22 PM Matt Baker <baker....@gmail.com> wrote:

Hey Arthur,

I may look into doing that. In the past people have just defined the vacuum sense as a thermistor for openpnp, but getting rid of whatever nonlinearity that introduces would make configuring vacuum thresholds better.  Raw voltage or ADC ratio would be a good step -- I'm not really certain yet if the sensor is ratiometric or absolute.  If we can identify the sensors they used maybe we could do native pressure output too.  I think generally we just need a threshold good enough tell if there is something on the nozzle or not, it doesn't seem like much precision is required.

What's the logic openpnp-side on this ? Is it something like :

* 1. Read pressure

* 2. If pressure is higher or lower than this value, do something, exit loop

* 3. GOTO 1

Or something else ?

Because it sounds like there is an opportunity here ( with a custom module ) to implement something like :

* Whenever pressure reaches a given value, do something specific ( internally send a configured M-code, or change a pin's state ( which can be done by sending a configure- M-code to a switch, so that's probably what we want for general usefulness )

* Or whenever a given M-code is received, check if pressure is at a given value and if it is do something specific and if not do nothing

* Or whenever a given M-code is received, *wait until* presure is at a given value and when it is do something specific

It feels to me that one of those is likely to be useful to openpnp ( and faster/better/more useful than the current way of doing things, as in : openpnp doesn't really need to be involved ) but I might be wrong. Can you tell me more on how it currently works ?

This ADC change for now was just a one liner to disable oversampling, which also knocked out an average of the last 4 system ADC reads in the low level ADC read function.  I'm not sure if that was there for noise or stability for the temp sensing,

Both yes.

but possibly the average of 4 would have to be moved into the thermistor code.  If I estimated correctly the extra average puts the response time in the neighborhood of 100s of ms.  I understand that the ADC on LPC produced a lot of glitches so I'm not sure how that factored in. This was a quick change and probably not the long term solution.

On the subject of M code outputs, at present is it possible to read an arbitrary digital gpio input using the switch module and an M code, or am I too dense to figure it out?

I'm not 100% sure what you mean. Specify : what causes an event, and what you want the event to cause in return. Switch allows to have pin events and m-code events as triggers/inputs, and pin control and m-code control as outputs. So you can do mcode->mcode, mcode->pin, pin->mcode and pin->pin ( though the "pair" ones are rarely used ).

For now I just put the Z head return and pull pin return detectors as Zmin/Zmax so I could get the status with M119.  One of the things I need to figure out for openpnp is how I can use those outputs to prevent unsafe x-y moves.

There are different ways to do this. You can use "soft endstops" ( smoothie feature name ) to prevent moves that go outside the allowed area ( once homed ), or you can use "limit switches" ( smoothie feature name ) to trigger an alarm ( machine stops, needs M999 to go again ) once one of the endstops ( hard/physical ones ) is triggered when it shouldn't be.

http://www.smoothieware.org/endstops covers both features.

I learned a couple things doing the port that could be good pull requests, I'll see about packaging them up.  Getting STM32 integrated might be messy unless some new abstractions are added,

I wouldn't prioritize this right now.

although Venelin on this list has already done a version of my changes using #defs for platform specific changes. That is against the smoothie ethos I think, so its hard to tell how it stands.

Yeah I'm not sure how we'd actually handle integrating back a port. Probably would involve a lot of work in the HAL side of things to make it as transparent as possible.

Matt

On Friday, January 25, 2019 at 1:35:07 PM UTC-8, Arthur Wolf wrote:

If you are going to be significantly modifying the ADC stuff, it could make sense to make a new module that does just that. Either just a module that causes a given M-code to report a 0-1024 or 0-3.3v value, or a module with different sensors ( the way temperaturecontrol has thermistor but also thermocouple etc ) where one sensor would be the "raw" values as just mentionned but you'd also have another sensor that would report the actual vacuum in the right units ( after you configure the right ratio in config ).

You don't *need* this, but it'd be a cool feature for Smoothie in general, and if it gets integrated into the mainstream Smoothie, then you'd likely get contributions/improvements there that you could then merge back into your port.

Something to think about.

As always awesome work ! ( and thanks for adding to the wiki )

--

You received this message because you are subscribed to the Google Groups "Desktop Pick and Place" group.
To unsubscribe from this group and stop receiving emails from it, send an email to desktop-pick-and-...@googlegroups.com.
To post to this group, send email to desktop-pic...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/desktop-pick-and-place/9c2388f8-8df7-451e-b92b-3869cf76624e%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Matt Baker]

What's the logic openpnp-side on this ? Is it something like : 

* 1. Read pressure

* 2. If pressure is higher or lower than this value, do something, exit loop

* 3. GOTO 1

Or something else ?

I searched briefly but couldn't find the code, Jason could clarify or point us there, but what I gather from the configuration is that it is just a spot check:

1. Plop nozzle where pick component should be.

2. Wait for a configurable delay.

3. Spot check vacuum sensor and compare to configurable threshold.

4. Branch by continuing to place the component or fault. The fault might pause the job in the gui or attempt to re-feed and re-pick depending on settings.

 

Because it sounds like there is an opportunity here ( with a custom module ) to implement something like :

* Whenever pressure reaches a given value, do something specific ( internally send a configured M-code, or change a pin's state ( which can be done by sending a configure- M-code to a switch, so that's probably what we want for general usefulness )

* Or whenever a given M-code is received, check if pressure is at a given value and if it is do something specific and if not do nothing

* Or whenever a given M-code is received, *wait until* presure is at a given value and when it is do something specific

This might be really useful for the pick up operation for speed. i.e. wait until we know the component is attached (but not longer than necessary), or timeout/fault. I suppose the "ok" is enough on success, but the host needs to react if there is a timeout. I'm not sure that something specific needs to be triggered, the host is mostly waiting to know when it succeeded to grab the component so it can make the next move. If you're really trying to go fast I suppose you may assume the pick succeeded and check the threshold later instead of waiting on the vacuum to be detected.  These machines anyway are not about that type of speed.

Once we figure out what we need it to be able to do, if you want to guide me on how to make it more generalized and useful for upstream smoothie I will implement it.  Doing the native pressure and/or raw voltage make sense as well.

 

I'm not 100% sure what you mean. Specify : what causes an event, and what you want the event to cause in return. Switch allows to have pin events and m-code events as triggers/inputs, and pin control and m-code control as outputs. So you can do mcode->mcode, mcode->pin, pin->mcode and pin->pin ( though the "pair" ones are rarely used ).

The goal is to do a simple safe z check -- the host wants to know, is the pull pin retracted and is z axis in home position. The simplest way just seemed like a read of the two pins that indicate these things.  So the trigger event would be an mcode to initiate a state check, and the result event would be? I don't think an mcode or a pin, unless an mcode can be sent controller to host.  My head seems to not quite be in the right paradigm.

For the pull pin, maybe its easier if there is a similar "wait" as discussed above -- just attempt to retract, and then wait for the sensor to confirm it has retracted. Ignore it the rest of the time.

For now I just put the Z head return and pull pin return detectors as Zmin/Zmax so I could get the status with M119.  One of the things I need to figure out for openpnp is how I can use those outputs to prevent unsafe x-y moves.

There are different ways to do this. You can use "soft endstops" ( smoothie feature name ) to prevent moves that go outside the allowed area ( once homed ), or you can use "limit switches" ( smoothie feature name ) to trigger an alarm ( machine stops, needs M999 to go again ) once one of the endstops ( hard/physical ones ) is triggered when it shouldn't be.

http://www.smoothieware.org/endstops covers both features.

The soft endstops are great, I configured those so the XY cannot be commanded to crash.  I think maybe the limit switch could be used for the safe Z, but its slightly complicated. Under normal operation -- any time the z axis is moved away from home -- the z endstop/home detector toggles. So you cannot just fault on that pin state. If any x-y move is attempted while the head is not home, then you want to fault.  Just reading the state before moving on the host side could be okay too.  I'll read the docs again and maybe skim the source.

Jason may have solved some of these things already, as smoothie has been used with openpnp for a long time.

Thanks for all the feedback,

Matt

[Arthur Wolf]

On Sat, Jan 26, 2019 at 2:52 AM Matt Baker <baker....@gmail.com> wrote:

What's the logic openpnp-side on this ? Is it something like : 

* 1. Read pressure

* 2. If pressure is higher or lower than this value, do something, exit loop

* 3. GOTO 1

Or something else ?

I searched briefly but couldn't find the code, Jason could clarify or point us there, but what I gather from the configuration is that it is just a spot check:

1. Plop nozzle where pick component should be.

2. Wait for a configurable delay.

3. Spot check vacuum sensor and compare to configurable threshold.

4. Branch by continuing to place the component or fault. The fault might pause the job in the gui or attempt to re-feed and re-pick depending on settings.

Ok to do that we just need a M-code that reports the sensor status, no need for further integration Smoothie-side.

 

Because it sounds like there is an opportunity here ( with a custom module ) to implement something like :

* Whenever pressure reaches a given value, do something specific ( internally send a configured M-code, or change a pin's state ( which can be done by sending a configure- M-code to a switch, so that's probably what we want for general usefulness )

* Or whenever a given M-code is received, check if pressure is at a given value and if it is do something specific and if not do nothing

* Or whenever a given M-code is received, *wait until* presure is at a given value and when it is do something specific

This might be really useful for the pick up operation for speed. i.e. wait until we know the component is attached (but not longer than necessary), or timeout/fault. I suppose the "ok" is enough on success, but the host needs to react if there is a timeout. I'm not sure that something specific needs to be triggered, the host is mostly waiting to know when it succeeded to grab the component so it can make the next move. If you're really trying to go fast I suppose you may assume the pick succeeded and check the threshold later instead of waiting on the vacuum to be detected.  These machines anyway are not about that type of speed.

Once we figure out what we need it to be able to do, if you want to guide me on how to make it more generalized and useful for upstream smoothie I will implement it.  Doing the native pressure and/or raw voltage make sense as well.

 

I'm not 100% sure what you mean. Specify : what causes an event, and what you want the event to cause in return. Switch allows to have pin events and m-code events as triggers/inputs, and pin control and m-code control as outputs. So you can do mcode->mcode, mcode->pin, pin->mcode and pin->pin ( though the "pair" ones are rarely used ).

The goal is to do a simple safe z check -- the host wants to know, is the pull pin retracted and is z axis in home position. The simplest way just seemed like a read of the two pins that indicate these things.

Wouldn't you just ask the board to go to the home position and to retract the pull pin ? That way if it's already there nothing happens and all is good, if it's not already there it gose there and all is good. What's the point of actually looking if it's there or not ?

  So the trigger event would be an mcode to initiate a state check, and the result event would be? I don't think an mcode or a pin, unless an mcode can be sent controller to host.  My head seems to not quite be in the right paradigm.

For the pull pin, maybe its easier if there is a similar "wait" as discussed above -- just attempt to retract, and then wait for the sensor to confirm it has retracted. Ignore it the rest of the time.

For now I just put the Z head return and pull pin return detectors as Zmin/Zmax so I could get the status with M119.  One of the things I need to figure out for openpnp is how I can use those outputs to prevent unsafe x-y moves.

There are different ways to do this. You can use "soft endstops" ( smoothie feature name ) to prevent moves that go outside the allowed area ( once homed ), or you can use "limit switches" ( smoothie feature name ) to trigger an alarm ( machine stops, needs M999 to go again ) once one of the endstops ( hard/physical ones ) is triggered when it shouldn't be.

http://www.smoothieware.org/endstops covers both features.

The soft endstops are great, I configured those so the XY cannot be commanded to crash.  I think maybe the limit switch could be used for the safe Z, but its slightly complicated. Under normal operation -- any time the z axis is moved away from home -- the z endstop/home detector toggles. So you cannot just fault on that pin state. If any x-y move is attempted while the head is not home, then you want to fault.  Just reading the state before moving on the host side could be okay too.  I'll read the docs again and maybe skim the source.

Jason may have solved some of these things already, as smoothie has been used with openpnp for a long time.

Thanks for all the feedback,

Matt

[Matt Baker]

Ok to do that we just need a M-code that reports the sensor status, no need for further integration Smoothie-side. 

Yeah right now we just use M105. Could be a little faster with the wait function discussed, but at present it works.

 

Wouldn't you just ask the board to go to the home position and to retract the pull pin ? That way if it's already there nothing happens and all is good, if it's not already there it gose there and all is good. What's the point of actually looking if it's there or not ?

This is what we do now.  Mostly we need to look because the mechanics are not reliable enough to assume it is working correctly open loop.  

The pull pin solenoid is dragging tapes and can get torqued and jammed or stuck. When I was bringing up the machine for my testing I ripped out a lot of holes in the tape this way.  

The head is on a cam mechanism with a spring return.  If the z motor skips for any reason (lower onto something high, exceed the axis), the spring force is strong enough that it pulls the motor all the way to 0 before it recovers.  Then attempting to return to home would be way off. If a pick or place height is misconfigured slightly this could happen.

Right now I just defined them as zmin and zmax so I can use M119 to read their state.  That was why I asked about arbitrary pin reads by M-code -- I wasn't sure if I should define them as end stops.

That said, in openpnp we can just poll their state after any z move or pin movement.  It might be faster and/or safer if the controller was watching them during all XY moves, but we do have a functional baseline.

 

[Arthur Wolf]

"Read this pin and if it's not the right state issue an alarm" is something we want to implement within Smoothie ( we need it for example for ATC spindles ). I think the easiest way to do that is as an extension to the Switch module ( or if you had an ADC module, same thing for that module ) though I'm not sure exactly how we'd do that exactly.

--

You received this message because you are subscribed to the Google Groups "Desktop Pick and Place" group.
To unsubscribe from this group and stop receiving emails from it, send an email to desktop-pick-and-...@googlegroups.com.
To post to this group, send email to desktop-pic...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/desktop-pick-and-place/1f0b4501-7494-4657-8cb2-6875970cc465%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Mark]

"Read this pin and if it's not the right state issue an alarm"

 

Sounds like an endstop with limit_enable = true

http://smoothieware.org/6axis

 

As a workaround, I mean. Don’t know if they work without specifying an axis. Or if attaching just any axis as a “dummy” has ill effects.

 

_Mark

[Arthur Wolf]

Well, we need the enstops for other things, here the idea would be to have a general purpose way of doing this on any pin, on as many pins as we need. It's this sort of modularity that ( in my opinion ) makes Smoothie such a good fit for pnp machines, and this sounds like a modularity thingie that's missing.

[Matt Baker]

Mark, in my understanding the present limit function is not quite a match for our z axis -- the detector circuit toggles any time the z axis moves, so alarm conditions would occur under normal operation.

The proposed feature would work well for this use case, because it would allow us to perform the alarm condition check only at specific times when the z is expected be clear.

Matt

[Matt Baker]

I threw together a simple IO and simple Camera board, so that those of us with 48VB will have an easier time connecting the machine up to run openpnp.  And to have a simple board to assemble with the machine.

I wanted the IO board personally because I couldn't come up with a way to connect to both serial interfaces without it being a giant kludge (rs232 controller side requires a 5v source that standard rs232-usb doesn't provide).  Its a single USB dual UART bridge, with an rs232 buffer and rs422 buffer.  Connector pinout and type match what the controller side needs so it can use off the shelf cables. I wanted the 2nd serial port so that I can manipulate gcode from an alternate terminal while openpnp is connected (maybe that was already provided within openpnp though).

The camera board is to feed 12v to the analog cameras, and break out the video signal to an RCA jack for use with a analog video-usb adapter.  The ones used on the 36VA are pretty generic and can be sourced cheaply.  The 36VA has an LC pi network on the video feed, that I'm not sure if that is a simple ferrite noise filter or an impedance matching network for the video mux.  I'll have to test that a bit, or desolder from the 36VA and test the passives.

Matt

[Dominic Clifton]

Hi Matt,

What's the latest on the Smoothie STM32/CHMT project?  I've been seriously overloaded with work recently and not had time to follow up on all this.

The USB PC video capture sticks that sent me the links for arrived a while ago. I tested on and it works fine on a spare camera I had here.

The RS422/485 to USB adapter also arrived.

Did you have time to make up the IO and camera boards? Do you have any spare?  I would at least like to bring up this spare controller board I have here with the Smoothie STM32 port on it.

Dominic

--
You received this message because you are subscribed to the Google Groups "Desktop Pick and Place" group.
To unsubscribe from this group and stop receiving emails from it, send an email to desktop-pick-and-...@googlegroups.com.
To post to this group, send email to desktop-pic...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/desktop-pick-and-place/1b65117f-3213-4c6c-97b0-96659a33d63e%40googlegroups.com.

[Nathan Seidle]

Hi Matt - Do you have a schematic that you can share? I'd be interested in possibly changing out our camera board. We constantly have the issue where the machine starts up, we open the software, and we have no camera feed. After multiple machine and software power cycles we can get the video feed to come up. I think this is due to a slightly faulty camera board.

--
Nathan Seidle, Founder

To view this discussion on the web visit https://groups.google.com/d/msgid/desktop-pick-and-place/CADpVWTEqRvHRt6%3DCbcmo7D1rPBYZKD3so9XJwEMCigzDO8tCLQ%40mail.gmail.com.

[Matt Baker]

Dominic,

Smoothie firmware is functional, but it is still a one way ticket requiring the microcontroller to be erased or chip swapped. As far as I know Jason brought up a second board in his 36VA and all machine features were functional.

I've been wrapped up in other projects, but I have everything on hand for a couple of each board ready to be assembled. This week I should have some time.

Nathan,

I've attached the schematic, but it is not a complete replacement for the 36VA board -- it only breaks out the camera connectors for attachment to a video capture card and injects 12V for power. It does not have the video multiplexer, so it would not work with the charmhigh software, only openpnp.

As to what might be wrong with the video board, it could be power/startup sequencing (timing of 12V, USB 5V, and the mux signal). The video converter might also just be junk. I've seen a couple of the boards now, and they do not all have the same video capture USB stick PCB bodged onto them.  As far as I can tell, they just removed the PCB from one of these types of dirt cheap converters. The fact that they are not even sourcing them consistently enough to have the same video converter IC is concerning.  If I were to attempt a repair, swapping out that PCB is probably the best bet.

Longer term, I won't need the 36VA board I have so that could be an option. I haven't use it enough to know whether it has the same issue or not.

Cheers,
Matt

On Monday, March 25, 2019 at 8:42:19 AM UTC-7, Nathan Seidle wrote:

Hi Matt - Do you have a schematic that you can share? I'd be interested in possibly changing out our camera board. We constantly have the issue where the machine starts up, we open the software, and we have no camera feed. After multiple machine and software power cycles we can get the video feed to come up. I think this is due to a slightly faulty camera board.

--
Nathan Seidle, Founder

On Sun, Mar 24, 2019 at 2:28 PM Dominic Clifton <domini...@gmail.com> wrote:

Hi Matt,

What's the latest on the Smoothie STM32/CHMT project?  I've been seriously overloaded with work recently and not had time to follow up on all this.

The USB PC video capture sticks that sent me the links for arrived a while ago. I tested on and it works fine on a spare camera I had here.

The RS422/485 to USB adapter also arrived.

Did you have time to make up the IO and camera boards? Do you have any spare?  I would at least like to bring up this spare controller board I have here with the Smoothie STM32 port on it.

Dominic

On Thu, Jan 31, 2019 at 10:53 PM Matt Baker <baker....@gmail.com> wrote:

I threw together a simple IO and simple Camera board, so that those of us with 48VB will have an easier time connecting the machine up to run openpnp.  And to have a simple board to assemble with the machine.

I wanted the IO board personally because I couldn't come up with a way to connect to both serial interfaces without it being a giant kludge (rs232 controller side requires a 5v source that standard rs232-usb doesn't provide).  Its a single USB dual UART bridge, with an rs232 buffer and rs422 buffer.  Connector pinout and type match what the controller side needs so it can use off the shelf cables. I wanted the 2nd serial port so that I can manipulate gcode from an alternate terminal while openpnp is connected (maybe that was already provided within openpnp though).

The camera board is to feed 12v to the analog cameras, and break out the video signal to an RCA jack for use with a analog video-usb adapter.  The ones used on the 36VA are pretty generic and can be sourced cheaply.  The 36VA has an LC pi network on the video feed, that I'm not sure if that is a simple ferrite noise filter or an impedance matching network for the video mux.  I'll have to test that a bit, or desolder from the 36VA and test the passives.

Matt

--
You received this message because you are subscribed to the Google Groups "Desktop Pick and Place" group.

To unsubscribe from this group and stop receiving emails from it, send an email to desktop-pick-and-place+unsub...@googlegroups.com.

To post to this group, send email to desktop-pic...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/desktop-pick-and-place/1b65117f-3213-4c6c-97b0-96659a33d63e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Desktop Pick and Place" group.

To unsubscribe from this group and stop receiving emails from it, send an email to desktop-pick-and-place+unsub...@googlegroups.com.

[Nathan Seidle]

Got it. Thanks for the thoughts: ordering a converter might be a good option for us!

--
Nathan Seidle, Founder

Dominic,

Cheers,
Matt

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

To post to this group, send email to desktop-pic...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/desktop-pick-and-place/1b65117f-3213-4c6c-97b0-96659a33d63e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Desktop Pick and Place" group.

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

To post to this group, send email to desktop-pic...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/desktop-pick-and-place/CADpVWTEqRvHRt6%3DCbcmo7D1rPBYZKD3so9XJwEMCigzDO8tCLQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "Desktop Pick and Place" group.

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

To post to this group, send email to desktop-pic...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/desktop-pick-and-place/daf53617-db1c-47da-adda-8c7ca94b3779%40googlegroups.com.

[Matt Baker]

The IO board is working well.  Running RS422 primary and RS232 debug simultaneously over the single USB connection.  I had fun debugging the board because I thought I could eyeball the pin 1 marker on the USB ESD protection, but I ended up mounting them backwards.

I don't have any camera capture cards to test the camera board, but there isn't much to it other than connectors.  I did not populate the pi filter with anything other than a 0 ohm resistor so we'll want to verify the signal isn't any noisier than expected.  Dominic, if you wouldn't mind testing it out, I think you have everything in hand.

I've got a couple extras of each populated if anyone else with a 48VB is interested. 

Matt

[Dominic Clifton]

Hi Matt,

Yes I can test an IO board out here.  I'll drop you an email with my details in.

Dominic

[Andreas Axelsson]

I tried to buy an additional controller board for the CHMT36VA from Kimi, but she didn't reply. Anyone successfully bought a spare board?

[Jason von Nieda]

I had to email her twice before she replied, but she eventually did, with a quote of $280 total, shipped via DHL.

Jason

On Fri, Apr 12, 2019 at 9:08 AM Andreas Axelsson <an...@teknikportfoljen.se> wrote:

I tried to buy an additional controller board for the CHMT36VA from Kimi, but she didn't reply. Anyone successfully bought a spare board?

--
You received this message because you are subscribed to the Google Groups "Desktop Pick and Place" group.
To unsubscribe from this group and stop receiving emails from it, send an email to desktop-pick-and-...@googlegroups.com.
To post to this group, send email to desktop-pic...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/desktop-pick-and-place/4886f661-e44c-4059-87e6-9bb54e4fb202%40googlegroups.com.

[Dominic Clifton]

I did when I bought my machine.

Dominic

[Matt Baker]

FYI, I was browsing Robotdigg looking for an epoxy dispensing solution, and noticed that they are now listing the CHMT36VA camera board for purchase.

https://www.robotdigg.com/product/1649/CHMT36VA-Vision-Capture-Board

I've upgraded both of the cameras in my machine to USB models, and am willing to sell the camera board that I have.

Cheers,
Matt

[Nathan Seidle]

Thanks for this link! We're going to order a new board and see if it fixes our no-camera-at-power-on issue.

--
Nathan Seidle, Founder

--

You received this message because you are subscribed to the Google Groups "Desktop Pick and Place" group.
To unsubscribe from this group and stop receiving emails from it, send an email to desktop-pick-and-...@googlegroups.com.
To post to this group, send email to desktop-pic...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/desktop-pick-and-place/0e7654c4-678e-442f-b886-0116bc2a3bed%40googlegroups.com.

[Wayne Black]

Matt

Can you elaborate on you potting process? Im in need of a epoxy/potting solution as well. My requirements are 100 units at 15ml/unit using MAX MCR. Currently Im manually cup pouring but this is messy and not very efficient. I was looking into disposable 2:1 cartridges and an epoxy gun, but the volume is too great. Automated dispensors are out of my price range at the moment. Looking for any clever workarounds if you know of any?

[Jarosław Karwik]

I did once stunt with two peristaltic pumps ( driven by stepper motors - you can "emulate" 2:1 cartriges using different stepping and e.g. arduino) connected to mixing nozzles .

It did not work because my epoxy was dripping from the nozzle - but if yours has higher viscosity then it may work

[Matt Baker]

Right now I don't have a solution. A technician just mixes a 2-part and applies it to each unit.

I was hoping to fit something automated, maybe to a 3d printer, but it I'm probably going to end up just having the technician apply it with an epoxy gun and mixing nozzle. If its still too slow we might try a pneumatic dispenser, still operated by a technician.  I think the volumes are still low for me to try to automate.

We're only blobbing a single IC (chip scale package) enough to block light. At 15mL a unit, that's a lot of epoxy so you probably need a different solution.

Matt

--
You received this message because you are subscribed to a topic in the Google Groups "Desktop Pick and Place" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/desktop-pick-and-place/C-n9dksqhDQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to desktop-pick-and-...@googlegroups.com.

To post to this group, send email to desktop-pic...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/desktop-pick-and-place/12f3fb66-cc5b-4d8b-afff-c440a16c2e31%40googlegroups.com.

[Wayne Black]

This give me the idea to maybe use a single stepper to trigger a dual cart gun like https://www.homedepot.com/p/JES-900-ml-2-1-26-1-High-Thrust-Dual-Component-Cartridge-Gun-D9/305860773. This seem to be the largest capacity I can get in a 2:1 configuration getting me ~50 units a cartridge at about $.10/unit in cartridge/nozzle cost. Probably money well spent as I fouled 100 units w poorly mixed epoxy that never cured and leaked all over the place. I was using a graduated squeeze bottle (ketchup bottle) w a small paddle mixer via a drill. Ive since gone back to the two cup pour method and there has to be a better way.

Thanks for the tips

[Richard Klosinski]

I just use 3M Scotch-Weld EPX Plus II Manual (https://www.amazon.com/3M-50004-Scotch-Weld-Plus-Applicator/dp/B001ANXYF4/ref=sr_1_fkmr0_1?keywords=3M+Scotch-Weld+EPX+Plus+II+Manual&qid=1558030140&s=gateway&sr=8-1-fkmr0) and 3M Scotch-Weld Epoxy Potting Compound (https://www.amazon.com/3M-Scotch-Weld-Epoxy-Potting-Compound/dp/B000X5G6O6/ref=sr_1_fkmrnull_4?keywords=3M+Scotch-Weld+EPX+Plus+II+Manual&qid=1558030258&s=gateway&sr=8-4-fkmrnull) with a mold with two holes (input and air escape). 

[Wayne Black]

That method would cost over $10/unit not including cost of nozzles, not realistic. I do use 3M DP190 to glue the pcbs down to the emclosure tho.

[Andrew Ferencz]

I am doing a project with a big OEM power supply company and we are using a compound that fills about 2" x 3" x 2" volume and cost less than $1.00 and is soft.  It comes from China and is used in automotive applications.  I think '1-part'.  I can get information about it if you need.  Shelf life under proper storage was about 2 years.

--

You received this message because you are subscribed to the Google Groups "Desktop Pick and Place" group.

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

To post to this group, send email to desktop-pic...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/desktop-pick-and-place/2ad83962-9d74-4233-bd43-e3d226f6f0df%40googlegroups.com.

[Sindre Vadla Ravnås]

Hi Andrew,

Did you get any information about this compouns used by this PSU company?

BR,

Sindre

To unsubscribe from this group and stop receiving emails from it, send an email to desktop-pick-and-place+unsub...@googlegroups.com.

[Andrew Cilia]

No, I settled for a hard epoxy used to anchor rebar on concrete. Cheap and super hard 

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

To post to this group, send email to desktop-pic...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/desktop-pick-and-place/2ad83962-9d74-4233-bd43-e3d226f6f0df%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "Desktop Pick and Place" group.

To unsubscribe from this group and stop receiving emails from it, send an email to desktop-pick-and-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/desktop-pick-and-place/73ff2215-16cd-46e9-bc4c-04d84c3f24af%40googlegroups.com.

[Per Eklund]

To save me some time I decided to by a CHMT36 that I will convert to OpenPnP.

There is a machine.xml at  GitHub - mattthebaker/openpnp-config-chmt at latest   but I guess it is for OpenPnP v1 since it does not load in OpenPnP 2.0

Does anyone here have a config for 2.0? It would save me some time not to invent the wheel again and config from scratch.

--Per Eklund

[Erich Styger]

I‘m running V2 on my machine. See https://www.google.ch/amp/s/mcuoneclipse.com/2020/05/03/retrofitting-a-charmhigh-chm-t36va-machine-with-openpnp/amp/ which has a link to a Github with the config.

Erich

Von meinem iPhone gesendet

Am 28.12.2020 um 16:23 schrieb Per Eklund <eklun...@gmail.com>:

To save me some time I decided to by a CHMT36 that I will convert to OpenPnP.

To view this discussion on the web visit https://groups.google.com/d/msgid/desktop-pick-and-place/34c6850e-82b6-4781-b231-e258c0f99d6bn%40googlegroups.com.

[ma...@makr.zone]

Nélio Oliveira <nelio...@gmail.com> seems to have a fast config with the latest OpenPnP using the latest Advanced Motion Control features including drag pin interlock:
https://groups.google.com/g/openpnp/c/CQX0uDciXp8/m/egCXht0VAgAJ

Video:
https://photos.app.goo.gl/746xagcWyGaWgGrDA

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/desktop-pick-and-place/1A703F76-323C-464F-BC3D-23A0778B711D%40gmail.com.

[Nélio Oliveira]

Yes, I have spend quite some time adjusting and improving the settings for CHMT36.

I have used the firmware from Matt Baker but did a few changes to the config file.

You can download the files here:

https://drive.google.com/drive/folders/1F6b5uMHJa-KNDDlsAYXWRyKv2iho84o-?usp=sharing

[Per Eklund]

Thanks a lot. I will use this as a starting point!

[Per Eklund]

Short follow up.

After removing the cameras in mashine.xml it started up.

I have two issues so far. 

1. I had to remove A and B axes in POSITION_REPORT_REGEX. They are not reported by M114.2 and there will be a timeout after some time.

2. I must probably set som switches on my Y-axes stepper driver. It steps 4x the commanded length. X-axis is spot on.

So again. Thanks a LOT for this config :-)

--Per

[dha...@gmail.com]

How is the accuracy and repeatability compared to Charmhigh firmware? Same, better, worse?

[Nélio Oliveira]

Not so fast/fluid as the original but way more versatile and accurate.

The ability to calibrate the runout of the nozzles makes a big difference.

Cumprimentos | Best regards,

Nélio Oliveira

To view this discussion on the web visit https://groups.google.com/d/msgid/desktop-pick-and-place/f62e8307-cfd4-4f52-81c5-bad0036776ffn%40googlegroups.com.

[ma...@makr.zone]

Hi

The newest Version of OpenPnP 2.0 (which Nélio uses) includes the new Advanced Motion Control feature set. This works best with my fork of Smoothieware (the reasons are explained here):

https://makr.zone/smoothieware-new-firmware-for-pnp/500/

Ideally Matt Baker would integrate my changes into his port ;-)

The POSITION_REPORT_REGEX problem should then disappear and other improvements should become available.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/desktop-pick-and-place/5eacc5f5-201a-497d-bab8-5cc992f6ebb6n%40googlegroups.com.

[Nélio Oliveira]

I'm actually using the latest test version.

I have tried to compile from your optimized version of Smoothieware for OpenPnP but without success. 

It would be really great if Matt Baker could do it.

I had to use M114.2 because in this version of Smoothieware M114 doesn't report all axis. 

Cumprimentos | Best regards

Nélio Oliveira

To view this discussion on the web visit https://groups.google.com/d/msgid/desktop-pick-and-place/ec73b495-b0e7-5a26-3bd7-1adc83d1ec59%40makr.zone.

[Chris]

The ENABLE_COMMAND in Nélio's xml has a "M92 Y127.8" command that is setting the steps/mm.  For my machine I use "M92 X31.94 Y31.94", which is probably why you are seeing 4x on the steps.

I have the same issue as you for the M114 query.  It's not getting the positions of the A or B axis.  However, the G0 command is able to use A and B to set their position and drive them at the same time: "G0 A10 B10" moves both nozzles at the same time. 

I found that the firmware-chmt.bin file in Nélio's zip is identical to the one in Matt Baker's github repository.  Nélio could you direct us to the bin file you used for programming?

Thanks,

Chris

[Per Eklund]

I fond the  "M92 Y127.8" . I just removed it and now it is spot on without any M92.

I think everything works now as expected.

I will have a look at Mark's changes on Smoothieware and I will try to implement them. 

I will also see if there are any free pins on the board. I want a couple of more functions.

Power for a coax-downlight and one pin for measuring hights with a laser module that I have.

If it is too much work or if I can't make the code to compile I make a separate controller for this.

Thanks

--Per

[Nélio Oliveira]

Yes, you're right! I forgot to mention that in the ENABLE_COMMAND.

I'm testing a different driver with the DRV8711 chip in the Y axis and it is configured for 1/32 microstepping.

The original drivers are TB6600 with 1/8.

The firmware file I have compiled is  \STM32F407xG\main.hex

Cumprimentos | Best regards,

Nélio Oliveira

To view this discussion on the web visit https://groups.google.com/d/msgid/desktop-pick-and-place/efc45f1f-0eca-4587-bed3-9df7bdb9cb19n%40googlegroups.com.

[Chris]

When I program with main.hex or main.bin in the STM32F407xG folder the M114.2 command gives "ok MCS: X:0.0000 Y:0.0000 Z:0.0000".  I'm not sure how you got it to work with the POSITION_REPORT_REGEX that looks for the A axis and B axis values.

Thanks,

Chris

[Nélio Oliveira]

Don't know what could be wrong there.

That's exactly how I got mine to work.

M114.2 returns "ok MCS: X:405.0094 Y:450.0000 Z:0.0000 A:179.7768 B:-0.2250 C:6.0060"

Cumprimentos | Best regards

Nélio Oliveira

To view this discussion on the web visit https://groups.google.com/d/msgid/desktop-pick-and-place/f624c7b3-7b51-4f27-8c8e-e02b147a17ebn%40googlegroups.com.

[Dave M]

Just a quick question. Does this work with the 48VB series? 

To view this discussion on the web visit https://groups.google.com/d/msgid/desktop-pick-and-place/f62e8307-cfd4-4f52-81c5-bad0036776ffn%40googlegroups.com.

[Chris]

That could be the difference I suppose, I am using a 48VB.

[Nélio Oliveira]

I suppose that the main difference could be that the controller board in 48VB has more components populated for the extra functionality (extra peeler, etc).

Cumprimentos | Best regards

Nélio Oliveira

To view this discussion on the web visit https://groups.google.com/d/msgid/desktop-pick-and-place/58bef3d7-f79c-4f83-9607-819088d1dc81n%40googlegroups.com.

[Chris]

Nélio's config.default file only defines axis A, B, and C.  Matt's config.default had another axis for defined for the 48VB's right side feeders.  However, when I program with Nélio's firmware the machine will actuate it's right feeders with "G92 D0 G0 D6" or "T3G92E0G0E5".  I thought maybe I did not actually reprogram the chip, but I read it's program in to a file and it matches the one from Nélio and is different than Matt's.  I'm not sure how it knows how to drive the D axis without it being in the smoothie config file.

[Nélio Oliveira]

Can you move both the left and right peelers?

Maybe they have different pinouts for step and direction than in 36VA.

Cumprimentos | Best regards

Nélio Oliveira

To view this discussion on the web visit https://groups.google.com/d/msgid/desktop-pick-and-place/f8e08122-1bc3-4a37-949d-d3fc02edd3e9n%40googlegroups.com.

[Chris]

Yes, I can move both peelers.  I think the left peeler uses pin 5.3 for step and 5.2 for direction.  I think the right peeler uses pin 5.7 for step and 5.6 for direction.  "G92 C0 G0 C5" will actuate the left peeler and "G92 D0 G0 D5" will drive the right peeler.

However, your smoothie config file has the extruder.f2 section commented out, so I'm not sure why the actuate right peeler works for me with your smoothie configuration since that axis doesn't seem to be defined with your config.

[Nélio Oliveira]

I'm finding that really strange as well.

I have commented the extruders section because I'm using axis letters instead for better compatibility with OpenPnP 2.0.

Cumprimentos | Best regards

Nélio Oliveira

You received this message because you are subscribed to a topic in the Google Groups "Desktop Pick and Place" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/desktop-pick-and-place/C-n9dksqhDQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to desktop-pick-and-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/desktop-pick-and-place/83dc5040-a301-4a70-a675-a165bd470758n%40googlegroups.com.