OpenPnP Control Boards

591 views
Skip to first unread message

John Socha-Leialoha

unread,
Aug 8, 2016, 6:20:18 PM8/8/16
to OpenPnP
I've been working on my pick and place machine and have it running in fully manual mode. The next step is to get it running with OpenPnP for semi-automatic and automatic modes (I currently have connect and homing working from OpenPnP). So far I've been using off the shelf hardware along with some breakout boards I made, but I have breadboards and a whole bunch of jumper wires all over the place. So my next step is to create a set of custom circuit boards specifically for OpenPnP, which will be open source, as will be the firmware. Here is an outline of what I'm thinking about having on the board:
  • ATMEGA32U4 (same as in the Arduino Leonardo)
  • 3 (or 4) Trinamic 5130A stepper motor controllers/drivers
  • RS-485 chip
  • Optional step-down converter (to convert 12 or 24 volts down to 5 volts to run the logic boards)
  • Two FETs with flyback diodes
  • General-purpose I/O pins
I chose the ATMEGA32U4 for a couple of reasons. First, it has USB built in, so there is no need for an additional USB to serial chip, like the FTDI chip. Second, it's fairly cheep and has plenty of power to handle OpenPnP's needs. And third, I happen to have 100 of them.

Spekaing of performance, I also chose the Trinamic 5130 chips because they handle all of the motion calculations and step generation, with support for accelearion and sensor-less endstops. I've shown this working in my separate thread on my "Assisted Manual" machine (poorly named, as it will also handle semi-automatic and automatic). I've written firmware to driver my machine, and it's not that much code, so there is plenty of EEPROM and RAM left for other functions.

As to the choice of the number of chips, my first thought is three per board, with the ability to add more boards connected via RS-485. I was thinking of three because this would handle X and two Y stepper motors, And then a second circuit board mounted to the head would handle Peter's head with one Z stepper and two head steppers. Of course, if enough people think it's a good idea, I can change this to four per board.

Additionally, I plan to have a second board without Trinamic chips that would be used for my control panel. The control panel is needed for manual and semi-automatic mode. And it might also be useful for feeder/board setup with fully automatic mode. The control panel board is basically like a Leonard with custom headers for connecting to the rotary encoders and other controls on the panel.

So, here are the questions:

Stepper Drivers
What do people think? Should have leave it at 3 drivers, or switch to 4? Keep in mind that it will be super easy to add more boards connected via RS-485 and power.

Control Language
I've just started to implement g code for connecting with OpenPnP. However, it occurred to me that there is really no reason it has to be g code, as I can make something that is very specific to OpenPnP. The idea is that I can provide a machine.xml file using the GCodeDriver, but with any control language I want. This would seem to provide more flexibility that sticking with g code. The other option is to use a hybrid of g code for some commands, perhaps some m code, and perhaps some custom codes. What do you think?

Thanks,
  -- John

Michael Anton

unread,
Aug 8, 2016, 6:30:08 PM8/8/16
to OpenPnP
If you are thinking it might be used to control the head as well, then adding in a couple of channels of strain gauge measurement would be handy for measuring vacuum sensors, so inexpensive pressure sensors could be used.  Having a couple more FETs with diodes would be good for 4 valve systems as well.

Jason von Nieda

unread,
Aug 8, 2016, 6:36:54 PM8/8/16
to ope...@googlegroups.com
I think there is value in using Gcode. Everyone knows it, everyone understands it, and it means it will be easy to use the board with existing Gcode programs like Pronterface, which can be helpful when setting up or debugging.

I would suggest at least keeping the major functions as Gcode and then feel free to be as creative as you want with the secondary stuff using Mcodes.

Jason

 
Control Language
I've just started to implement g code for connecting with OpenPnP. However, it occurred to me that there is really no reason it has to be g code, as I can make something that is very specific to OpenPnP. The idea is that I can provide a machine.xml file using the GCodeDriver, but with any control language I want. This would seem to provide more flexibility that sticking with g code. The other option is to use a hybrid of g code for some commands, perhaps some m code, and perhaps some custom codes. What do you think?

Thanks,
  -- John

--
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 post to this group, send email to ope...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/f85de02a-bbbf-4db9-a54f-402d03b5355d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Obi Wan

unread,
Aug 8, 2016, 6:45:10 PM8/8/16
to OpenPnP
I would recommend five stepper drivers, X,Y,Z, and rotate two heads.


On Monday, August 8, 2016 at 4:20:18 PM UTC-6, John Socha-Leialoha wrote:

Joao Matos

unread,
Aug 8, 2016, 7:01:13 PM8/8/16
to OpenPnP
Why go through the trouble of developing your own board and not use something like the Smoothieboard (or the cheap and readily available compatible MKS SBase clone)?

It already seems to provide pretty much all of the features you would need or at least a solid base to build upon (besides the Trinamic 5130 sensorless endstop I guess).

And from what I've read Smoothie v2 will provide a pretty nice extensible board interface that could be used to easily connect the head/vacuum add-on board.

From a developer's perspective their codebase is open source, pretty clean and easily extensible if you know C++.

Think it'd be more useful to focus on developing a Smoothie compatible head board that could work with Peter's head design and handle all of the custom PnP electronics like pressure/vacuum sensors and maybe also a feeder management board.

I'd be willing to help with the all of needed software to drive it, if someone else can do the hardware :)

John Socha-Leialoha

unread,
Aug 8, 2016, 7:17:01 PM8/8/16
to OpenPnP
Thanks Jason, that makes sense. I've already started down that road, but thought it made sense to ask.

Mark Harris

unread,
Aug 8, 2016, 7:17:47 PM8/8/16
to ope...@googlegroups.com
My main machine has two PCBs with microcontrollers on them to support the smoothie - the smoothie can't quite do everything we need, so I dont see an issue with making a supplemental board or complete replacement for the smoothie with more capability (V2 will probably have everything we need when its done though).

However I have to disagree with you on microcontroller choice. For a third of the price you can get a 32bit ARM Cortex M3 with USB, running 48-72mhz with a ton more ram, flash, timers, probably CAN hardware, etc. The atmega makes no sense financially or from a hardware perspective.

@Michael Anton, strain gauges need around 256x gain before you can begin to read them with a microcontroller. I use the TI ADS1220 for pretty much all my strain gauge applications, 960Hz, 128x PGA, and *24bit*. A 12bit ADC in a micro wont show you much, even with 256x gain :(. Reading strain gauges is expensive if you want to do it even remotely accurately.

John, don't let others put you off because there is another solution. If it something you'd benefit from then its worth doing :)

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

To post to this group, send email to ope...@googlegroups.com.

John Socha-Leialoha

unread,
Aug 8, 2016, 7:18:27 PM8/8/16
to OpenPnP
The idea is that you would get 5 steppers by connecting a second board. The first board would give you 3 steppers, and the second an additional three steppers. Because the two boards are connected by RS-485 and power, you can easily place the second board on the head to control the Z and two heads, which reduces the number of wires that you have to run to the head.

John Socha-Leialoha

unread,
Aug 8, 2016, 7:23:33 PM8/8/16
to OpenPnP
My main reason for going this route was the introduction of a control panel, and therefore RS-485. I wanted a lot of functionality in the control panel that interacts with the main board. By using the Trinamic chips, the amount of code is pretty small, so it's a lot easier to understand and customize the code. Sure, I could have gone the Smoothieboard route, but it probably would have involved a lot more customization. I'm hoping to make it very easy, with little to no customization, to add more boards. This will also make it easy to build multi-head machines if you want, or to add support for feeders later.

John Socha-Leialoha

unread,
Aug 8, 2016, 7:35:23 PM8/8/16
to OpenPnP
Thanks Mark, I plan to see this through because it's what I want. As I mentioned before, one of the reasons I chose the ATMEGA32U4 is because I already have 100 of them, and no other plans for using those chips. Plus, I've done some other designs that use this chip, so I know how to use it.

If I went the ARM route, it would certainly be more powerful. However, there are two things about using the ARM. First, I don't have experience with designing and programming ARM boards from scratch, whereas I have plenty of experience with the AVR chips. And second, because I'm using the Trinamic chips, performance, flash size, and memory size are just not an issue for this application. The Trinamic chip is doing all of the heavy lifting. I just need to send it speed and target position information via SPI, and then it takes it from there.

That being said, I haven't completely ruled out ARM chips. It's just that I didn't want to take the time to learn what I would need to learn. One other thing I should mention is that I'm using the Arduino toolchain for the firmware (but not the IDE). Since that's broadly available, it's easy for people to work with.

  -- John

Michael Anton

unread,
Aug 8, 2016, 7:47:04 PM8/8/16
to OpenPnP
Yes, I am aware of the requirements for strain gauges, as I've used them many times.  For a few more bucks you could get one of the Cortex micros with an on board 24bit A/D with PGA front end and differential inputs.  No extra hardware required.  Directly reading unamplified pressure sensors is painless using these sorts of parts.  Something like the PSOC5 would give all sorts of capability beyond that as well, though I haven't worked with them.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

John Socha-Leialoha

unread,
Aug 8, 2016, 9:22:33 PM8/8/16
to OpenPnP
I did some more research into ARM chips, and things have changed a lot since the last time I looked. I'm now leaning toward using the ATSAM21DG18 that is used in the Arduino Zero. This is less expensive than the ATMEGA32U4, and, of course, is an ARM. It looks like it's not that hard to burn the bootloader, except that you need the Atmel ICE, which isn't cheap.

Michael Anton

unread,
Aug 8, 2016, 10:28:59 PM8/8/16
to OpenPnP
Many ARM chips these days have built in boot loaders, and some even support multiple interfaces.  Supporting the UART interface is pretty common, though not likely over RS485, and others support ethernet, and USB.  The ones that enumerate as a USB flash drive make code upgrade simple, with no extra tools required.  Personally, I wouldn't want to limit my choices to what the Arduino toolchain supports, especially since it is pretty terrible anyhow.

Mark Farver

unread,
Aug 8, 2016, 11:24:24 PM8/8/16
to ope...@googlegroups.com

Trimetic has a 5 channel hat for the Beaglebone, and supporting code for offloading most of the work to the Beaglebone's onboard coprocessors. 

Put a small touchscreen on it for local control, jog and stats.  A remote PC does the vision and runs OpenPNP.

Mark

Mark Harris

unread,
Aug 9, 2016, 12:24:52 AM8/9/16
to ope...@googlegroups.com
Pretty much all of the NXP ARMs with USB will enumerate as a mass storage device with ISP_0 is low and ISP_1 is high. The Atmel JTAG is a total ripoff, pretty much everyone else has $10-30 dev kits with a J-Link or CMSIS-DAP debugger built into it, which can also debug external ARM targets (not just their target chip, I can use a SiLabs dev board to program an NXP chip for example).

The ease of Arduino's libraries, but with all the other things you wish it had... including a web based compiler. All the dev boards which are compatible (there's a LOT) implement USB mass storage device programmer, just save the bin file you download from the online compiler into the drive and your target is programmed. Couldn't be easier. When you're ready to migrate away from the web based compiler, or need to step through code as you debug it, inspecting variables/memory/registers as you go, you can download your project ready to go for a pretty large number of IDEs (mostly eclipse based, but also commercial like uVision and IAR).

As an advantage, there's also source control built in, with the ability to publish your project for others to fork/change.. if you're looking to create something community oriented, thats always neat. You can see other people's code at: https://developer.mbed.org/code/ - for example the LSR SiFlex02 modules I'm currently working with: https://developer.mbed.org/users/Issus/code/LsrModule/ - there's libraries for pretty much everything on there, some good, some bad... but pretty much all of them work heh.


To those who have seen my spiel before: yes, i will push ARM onto every unbeliever I come across who is still using 1990's tech.

--
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+unsubscribe@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

John Socha-Leialoha

unread,
Aug 9, 2016, 12:47:54 AM8/9/16
to OpenPnP
I first used MBED a few years ago, and I have a couple of their boards. For whatever reason, I ended up going down the Arduino path. I'm also using ESP8266 Arduino on another project, so it's nice to be able to switch between processors and have the same (or generally the same) libraries available. None of my projects push the limits of the hardware I'm using, so I'm fine with use the high-level libraries.

I'm using Visual Studio (which is a development environment I've been using for years) along with Visual Micro. Right now I have everything stored in GIT on Visual Studio Online (free for small teams, like myself). But I plan to move the GIT repository to GitHub soon. For me this project is mainly about building the pick and place machine that allows multiple modes (manual, semi-automatic, and automatic) using OpenPnP and a physical control panel. Since I've already written much of the firmware using Arduinos, switching to a SAMD21 with the Arduino libraries is the easiest thing for me.

As you can probably tell, I'm going to give the ARM chip a try instead of using an AVR. As I understand, the SAMD21 chips don't come with a bootloader, which means I'll need some way to burn the bootloader. Are there options other than the Atmel ICE (which looks to be around $140 right now)?

On Monday, August 8, 2016 at 9:24:52 PM UTC-7, Mark Harris wrote:
Pretty much all of the NXP ARMs with USB will enumerate as a mass storage device with ISP_0 is low and ISP_1 is high. The Atmel JTAG is a total ripoff, pretty much everyone else has $10-30 dev kits with a J-Link or CMSIS-DAP debugger built into it, which can also debug external ARM targets (not just their target chip, I can use a SiLabs dev board to program an NXP chip for example).

The ease of Arduino's libraries, but with all the other things you wish it had... including a web based compiler. All the dev boards which are compatible (there's a LOT) implement USB mass storage device programmer, just save the bin file you download from the online compiler into the drive and your target is programmed. Couldn't be easier. When you're ready to migrate away from the web based compiler, or need to step through code as you debug it, inspecting variables/memory/registers as you go, you can download your project ready to go for a pretty large number of IDEs (mostly eclipse based, but also commercial like uVision and IAR).

As an advantage, there's also source control built in, with the ability to publish your project for others to fork/change.. if you're looking to create something community oriented, thats always neat. You can see other people's code at: https://developer.mbed.org/code/ - for example the LSR SiFlex02 modules I'm currently working with: https://developer.mbed.org/users/Issus/code/LsrModule/ - there's libraries for pretty much everything on there, some good, some bad... but pretty much all of them work heh.


To those who have seen my spiel before: yes, i will push ARM onto every unbeliever I come across who is still using 1990's tech.
On 8 August 2016 at 21:24, Mark Farver <mfa...@mindbent.org> wrote:

Trimetic has a 5 channel hat for the Beaglebone, and supporting code for offloading most of the work to the Beaglebone's onboard coprocessors. 

Put a small touchscreen on it for local control, jog and stats.  A remote PC does the vision and runs OpenPNP.

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 post to this group, send email to ope...@googlegroups.com.

Mark Harris

unread,
Aug 9, 2016, 12:55:27 AM8/9/16
to ope...@googlegroups.com
Pretty much any SWD JTAG will work for hitting it with code, when setup right... just a matter of what your IDE will support. Check out the CoLinkEx: http://www.coocox.org/hardware/colinkex.php, make sure the atmel you want to use is supported: http://www.coocox.org/wiki/coocox/CoLinkEx/CoLinkEx-Support - You probably wont be able to debug through atmel studio (Built on VS Shell)/visual studio to debug it, but thats not really losing anything over using avrs *shrug*.

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

To post to this group, send email to ope...@googlegroups.com.

matt

unread,
Aug 9, 2016, 1:06:21 AM8/9/16
to ope...@googlegroups.com, Mark Harris
Why RS485 out of interest? CANbus is so much better. All the hard/fun
work is done for you, its a hardened protocol that is in use
everywhere... planes, trains and automobiles!

LPC11C24.. built in transceivers and a CANbus boot loader already in
ROM, £2 in single-offs

On 2016-08-09 05:55, Mark Harris wrote:
> Pretty much any SWD JTAG will work for hitting it with code, when
> setup right... just a matter of what your IDE will support. Check out
> the CoLinkEx: http://www.coocox.org/hardware/colinkex.php [6], make
> sure the atmel you want to use is supported:
> http://www.coocox.org/wiki/coocox/CoLinkEx/CoLinkEx-Support [7] - You
> probably wont be able to debug through atmel studio (Built on VS
> Shell)/visual studio to debug it, but thats not really losing anything
> over using avrs *shrug*.
>
>> Check out MBED: https://developer.mbed.org/cookbook/Homepage [1]
>> The ease of Arduino's libraries, but with all the other things you
>> wish it had... including a web based compiler. All the dev boards
>> which are compatible (there's a LOT) implement USB mass storage
>> device programmer, just save the bin file you download from the
>> online compiler into the drive and your target is programmed.
>> Couldn't be easier. When you're ready to migrate away from the web
>> based compiler, or need to step through code as you debug it,
>> inspecting variables/memory/registers as you go, you can download
>> your project ready to go for a pretty large number of IDEs (mostly
>> eclipse based, but also commercial like uVision and IAR).
>>
>> As an advantage, there's also source control built in, with the
>> ability to publish your project for others to fork/change.. if
>> you're looking to create something community oriented, thats always
>> neat. You can see other people's code at:
>> https://developer.mbed.org/code/ [2] - for example the LSR SiFlex02
>> modules I'm currently working with:
>> https://developer.mbed.org/users/Issus/code/LsrModule/ [3] - there's
>> libraries for pretty much everything on there, some good, some
>> bad... but pretty much all of them work heh.
>>
>> To those who have seen my spiel before: yes, i will push ARM onto
>> every unbeliever I come across who is still using 1990's tech.
>>
>> On 8 August 2016 at 21:24, Mark Farver <mfa...@mindbent.org> wrote:
>>
>> Trimetic has a 5 channel hat for the Beaglebone, and supporting code
>> for offloading most of the work to the Beaglebone's onboard
>> coprocessors.
>>
>> Put a small touchscreen on it for local control, jog and stats. A
>> remote PC does the vision and runs OpenPNP.
>>
>> 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 post to this group, send email to ope...@googlegroups.com.
>> To view this discussion on the web visit
>>
> https://groups.google.com/d/msgid/openpnp/CACNU6M7ExDCmVY9uf6Kb4yaZYtKciPCMstRBDV00ZJ7T-s1TXQ%40mail.gmail.com
>> [4].
>>
>> For more options, visit https://groups.google.com/d/optout [5].
>
> --
> 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 post to this group, send email to ope...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/openpnp/f820a802-e3d1-42c9-9bf9-16960199f840%40googlegroups.com
> [8].
>
> For more options, visit https://groups.google.com/d/optout [5].
>
> --
> 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 post to this group, send email to ope...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/openpnp/CAJMBTyRoTUDQs1uYLyD6x7yboDm%2BxFr_mxW18d0sZ%3DfGY-PNHQ%40mail.gmail.com
> [9].
> For more options, visit https://groups.google.com/d/optout [5].
>
>
> Links:
> ------
> [1] https://developer.mbed.org/cookbook/Homepage
> [2] https://developer.mbed.org/code/
> [3] https://developer.mbed.org/users/Issus/code/LsrModule/
> [4]
> https://groups.google.com/d/msgid/openpnp/CACNU6M7ExDCmVY9uf6Kb4yaZYtKciPCMstRBDV00ZJ7T-s1TXQ%40mail.gmail.com?utm_medium=email&amp;utm_source=footer
> [5] https://groups.google.com/d/optout
> [6] http://www.coocox.org/hardware/colinkex.php
> [7] http://www.coocox.org/wiki/coocox/CoLinkEx/CoLinkEx-Support
> [8]
> https://groups.google.com/d/msgid/openpnp/f820a802-e3d1-42c9-9bf9-16960199f840%40googlegroups.com?utm_medium=email&amp;utm_source=footer
> [9]
> https://groups.google.com/d/msgid/openpnp/CAJMBTyRoTUDQs1uYLyD6x7yboDm%2BxFr_mxW18d0sZ%3DfGY-PNHQ%40mail.gmail.com?utm_medium=email&utm_source=footer

Mark Harris

unread,
Aug 9, 2016, 1:20:00 AM8/9/16
to ope...@googlegroups.com
I'm using RS-485 in my machine, CAN is kinda awful as a protocol in my mind. Either you stick data in the header, or you have a MASSIVE header to transfer 1 byte of data. Great for trains/planes/automobiles with huge amounts of devices that need varying levels of priority... but overkill for a pick and place machine. RS485 is as fast as the serial port in your micro (half a megabit to 2+ megabit), running two RS485 lines its the same as a serial port with multiple devices on it and industrial noise immunity. Simple and functional, even with just one transceiver.


 To post to this group, send email to ope...@googlegroups.com.
 To view this discussion on the web visit
https://groups.google.com/d/msgid/openpnp/f820a802-e3d1-42c9-9bf9-16960199f840%40googlegroups.com
[8].

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


 --
 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,

 To post to this group, send email to ope...@googlegroups.com.
 To view this discussion on the web visit
--
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+unsubscribe@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

John Socha-Leialoha

unread,
Aug 9, 2016, 1:23:51 AM8/9/16
to ope...@googlegroups.com

I agree with Mark. I did some work with CAN about 10 years ago, so my knowledge isn't current. However, using RS-485 was super simple. I just attached the TX and RX lines for a hardware UART to a transceiver. And then created a really simple master/slave protocol. I'm currently running the UART at about 500K, which is plenty fast enough. This only took me a couple of hours to hook up and get working the first time. As I recall, CAN took a lot of reading of data sheets to get running.

 

My plan is to allow working with multiple slaves all on the same two wires. So that means each board only needs one tranciever.

Graeme Bridge

unread,
Aug 9, 2016, 1:52:35 AM8/9/16
to OpenPnP
one thing with the drivers is people tend to limit the XYZ to 1 stepper motor, I plan on using doubles for x y and z will probably end up with 4. so I'm already needing 8 drivers 

Rich Obermeyer

unread,
Aug 9, 2016, 2:35:57 AM8/9/16
to ope...@googlegroups.com
While I like the RS485 myself also, I have designed ASICs with both CAN and UARTs in them but 
The CAN is very strong in a noisy environment which a PNP is.  Reliability of CAN is unmatched. 
PNP does not send more than a headers worth of data at one time.  So it matches CAN architecture.
CAN is much easier to debug in a large system. RS485 with 30 nodes could be a significant problem to debug.

So if someone offered me the LPC11C24 with CAN BUS with a simple software driver written for OpenPNP I would say CAN beats the RS485 easily.  It's not overkill at $2.00 with a nice driver written for the PNP purpose.  Once the PNP driver is written the CAN BUS is a none issue to all the users.
--
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 post to this group, send email to ope...@googlegroups.com.

John Socha-Leialoha

unread,
Aug 25, 2016, 3:48:28 PM8/25/16
to OpenPnP
I've been making progress on designing the schematics, and am getting close to laying out the board. Below is my current set of choices, and I'd like to get feedback before I finalize the design:
  • ATSAMD21G18
  • Trinamic TMC5130A (three of four)
  • NCV8403ASTT1G low side drivers (2) for vacuum pumps. These are rated at 42V and 14A, so can easily handle vacuum pumps
  • ZXMN4A06GTA  MOSFETS (4) for solenoids, LED lights, etc. These are the same MOSFETs used by the Smoothie board
  • RS-485 Driver -- I haven't chosen the chip yet
I have flyback diodes across all 6 of the solenoid/pump connections.

I'm planning to use two of these boards for my single-head machine. One board will control the X and Y (2 steppers for Y) and the vacuum pump. The other board will control the head, the vacuum solenoid, and perhaps some LEDs. I'll also have some extra I/O pins I'll make available, which will include analog inputs for reading various sensors.

Here is one question. I'm wondering how many input supplies I should have. Here are the options:
  1. One supply for the steppers, "large" MOSFSETs, and "small" MOSFETS
  2. One supply for steppers, and a second supply input for all the MOSFETS
  3. Separate inputs for steppers, "large" MOSFETs, and "small" MOSFETS
The advantage of not using a single supply is that you could have, for example, a 24V supply for the steppers, and 12V for solenoids, LEDs, etc. I'm currently leaning toward option 2.

Thoughts?

Thanks,
  -- John

Jason von Nieda

unread,
Aug 25, 2016, 3:51:54 PM8/25/16
to OpenPnP
John,

Here's my votes:

* Option 2 for the power supplies, except include a jumper so you can bind the two together if you don't want to wire both.
* Include real jumpers or at least solder jumpers for the diodes in case people are using non inductive loads.

Other than that it sounds awesome!

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 post to this group, send email to ope...@googlegroups.com.

John Socha-Leialoha

unread,
Aug 25, 2016, 4:02:02 PM8/25/16
to OpenPnP
Thanks, Jason.

Unless I'm missing something, which is entirely possible, it seems like the diodes would have no impact when the MOSFETs are used with a non-inductive load. So do I need an option to remove them from the circuit?

Also, when you say include a jump, am I correct in understanding that this would tie VMotor to VSolenoid so you don't have to wire up VSolenoid?

Thanks,
  -- John

Peter Betz

unread,
Aug 25, 2016, 4:02:41 PM8/25/16
to OpenPnP, ma...@rris.com.au, ma...@mattbrocklehurst.co.uk


On Monday, August 8, 2016 at 10:06:21 PM UTC-7, matt wrote:

work is done for you, its a hardened protocol that is in use
everywhere... planes, trains and automobiles!
 

ARINC 429 is the standard for aviation. I think the A380 was the first to use CAN, and that wasn't that long ago. Not sure how that is working out for them.
Just a random fun fact :) 

Jason von Nieda

unread,
Aug 25, 2016, 4:05:51 PM8/25/16
to OpenPnP, ma...@rris.com.au, ma...@mattbrocklehurst.co.uk
John,

I can't think of a good reason that the diodes would cause a problem, but I am not much of an EE. Perhaps someone else would have input. I was mostly just thinking of it from a "just in case" perspective. 

And yep, the jumper would connect vmotor to vsolenoid to avoid extra wiring.

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 post to this group, send email to ope...@googlegroups.com.

evilwulfie

unread,
Aug 25, 2016, 4:16:59 PM8/25/16
to ope...@googlegroups.com
I don't know what your schematic looks like but
here is the datasheet for your FET
It has a parasitic diode in the FET already
adding one should not hurt

http://www.diodes.com/_files/datasheets/ZXMN4A06G.pdf

John Socha-Leialoha

unread,
Aug 25, 2016, 4:20:08 PM8/25/16
to ope...@googlegroups.com

I asked about this over on the EEVBlog forum and people said I should have a separate diode across the terminals so the current will stay within the motor once I shut the MOSFET off: http://www.eevblog.com/forum/beginners/mosfet-and-flyback-diodes/

 

  -- John

 

From: ope...@googlegroups.com [mailto:ope...@googlegroups.com] On Behalf Of evilwulfie
Sent: Thursday, August 25, 2016 10:17 PM
To: ope...@googlegroups.com
Subject: Re: [OpenPnP] Re: OpenPnP Control Boards

 

I don't know what your schematic looks like but

--
You received this message because you are subscribed to a topic in the Google Groups "OpenPnP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openpnp/X7frlnuvs0k/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openpnp+u...@googlegroups.com.


To post to this group, send email to ope...@googlegroups.com.

Rich Obermeyer

unread,
Aug 25, 2016, 4:23:53 PM8/25/16
to ope...@googlegroups.com
That's simply the body diode.  
You will still need an external diode for anything with magnetic kickback.  
Stepper motors generate significant amounts of that when the power is ON or OFF.

On Thu, Aug 25, 2016 at 1:17 PM, evilwulfie <evilw...@gmail.com> wrote:
I don't know what your schematic looks like but
here is the datasheet for your FET
It has a parasitic diode in the FET already
adding one should not hurt

http://www.diodes.com/_files/datasheets/ZXMN4A06G.pdf


On 8/25/2016 1:05 PM, Jason von Nieda wrote:
John,

I can't think of a good reason that the diodes would cause a problem, but I am not much of an EE. Perhaps someone else would have input. I was mostly just thinking of it from a "just in case" perspective. 

And yep, the jumper would connect vmotor to vsolenoid to avoid extra wiring.

Jason


On Thu, Aug 25, 2016 at 1:02 PM Peter Betz <betzt...@gmail.com> wrote:


On Monday, August 8, 2016 at 10:06:21 PM UTC-7, matt wrote:

work is done for you, its a hardened protocol that is in use
everywhere... planes, trains and automobiles!
 

ARINC 429 is the standard for aviation. I think the A380 was the first to use CAN, and that wasn't that long ago. Not sure how that is working out for them.
Just a random fun fact :) 
--
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+unsubscribe@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/5bd3f725-9db3-4dd1-a341-090a6d498fd4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
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+unsubscribe@googlegroups.com.

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

To post to this group, send email to ope...@googlegroups.com.

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



--
Rich

Jacob Christ

unread,
Aug 25, 2016, 4:28:15 PM8/25/16
to ope...@googlegroups.com
The "parasitic" diode in the FET will not protect the FET from a reverse voltage from a collapsing field.  The collapsing field can be in the 100V range.

Jacob

On Thu, Aug 25, 2016 at 1:17 PM, evilwulfie <evilw...@gmail.com> wrote:
I don't know what your schematic looks like but
here is the datasheet for your FET
It has a parasitic diode in the FET already
adding one should not hurt

http://www.diodes.com/_files/datasheets/ZXMN4A06G.pdf



On 8/25/2016 1:05 PM, Jason von Nieda wrote:
John,

I can't think of a good reason that the diodes would cause a problem, but I am not much of an EE. Perhaps someone else would have input. I was mostly just thinking of it from a "just in case" perspective. 

And yep, the jumper would connect vmotor to vsolenoid to avoid extra wiring.

Jason


On Thu, Aug 25, 2016 at 1:02 PM Peter Betz <betzt...@gmail.com> wrote:


On Monday, August 8, 2016 at 10:06:21 PM UTC-7, matt wrote:

work is done for you, its a hardened protocol that is in use
everywhere... planes, trains and automobiles!
 

ARINC 429 is the standard for aviation. I think the A380 was the first to use CAN, and that wasn't that long ago. Not sure how that is working out for them.
Just a random fun fact :) 
--
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+unsubscribe@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/5bd3f725-9db3-4dd1-a341-090a6d498fd4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
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+unsubscribe@googlegroups.com.

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

To post to this group, send email to ope...@googlegroups.com.

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



--
Jacob Christ
ProLinear/PONTECH, Inc.
+1 (909) 652-0670 Phone
http://www.pontech.com

Mark Harris

unread,
Aug 25, 2016, 5:19:30 PM8/25/16
to ope...@googlegroups.com
The idea of the diode is to prevent a "negative" voltage (relative to your supply) which will kill your fet instantly. A 25V fet getting a 30V spike will die after 2-3 of them, assuming it survives the first. The energy in an inductor (motor coil, solenoid) will collapse to a high potential voltage, the diode changes clamps that changing it to a high amp spike essentially.

For one of the h-bridges I'm working at work, without (big) diodes its a ~600v spike. With diodes it's a 40V spike and 300amps for a few microseconds. Diodes save FETs :)

Wireb

unread,
Aug 25, 2016, 6:02:28 PM8/25/16
to OpenPnP
And the diode must be across the inductive device not across the fet (which is where the body diode is) 

Michael Anton

unread,
Aug 25, 2016, 6:20:32 PM8/25/16
to OpenPnP, ma...@rris.com.au, ma...@mattbrocklehurst.co.uk
Diodes don't pose a problem, regardless of the load.  They can slow down the turn off time of the solenoid though, as the diode keeps the current flowing in the coil for a longer period of time than if the diode wasn't present.  The best plan, is to have quite high voltage FETs, and use a diode and zener diode in series, so that the voltage is allowed to fly back, but is kept within the limits of the FET.  This dumps the energy stored in the core into the zener diode (you will have to watch the power rating on this as a result), and will give the fastest switching times for inductive loads.

John, are you doing anything to protect against ESD events on all of the terminals?  That is always a good thing to have if you want the board to be reliable.

Mike

Matt Baker

unread,
Aug 25, 2016, 6:27:32 PM8/25/16
to OpenPnP, ma...@rris.com.au, ma...@mattbrocklehurst.co.uk
It can only really cause a problem if someone wants to use the MOSFET to switch a peripheral with a higher voltage than the diode feeds too. 

i.e. If the board is designed to feed 12V to the peripheral, the flyback diode will be from the FET drain to 12V supply.  If someone were to wire a fan for example directly to a +24V supply, with the low side to the FET, then in the FET off state the fan will be biased through the diode from +24V to the 12V supply.  Without the diode the FET is open drain and can support any load less than the breakdown voltage (external flyback required of course for inductive load).

This can in some cases be fixed by placing the flyback diode to the highest voltage available at the board.  When doing this you would want to consider the effect of dumping energy from the 12V to 24V supply for example.

Michael Anton

unread,
Aug 25, 2016, 6:28:02 PM8/25/16
to OpenPnP
It isn't a negative voltage relative to the supply on turn off, it's only negative on turn on, which is intended.  Since the inductor was pulled to ground, and flybacks when turned off, it will be a positive voltage relative to the supply, which over voltages the FET.

If the FET body diode is avalanche rated for repetitive pulses, like and IRFZ44 for instance, then the body diode can be used.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/5bd3f725-9db3-4dd1-a341-090a6d498fd4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
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.

--
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 post to this group, send email to ope...@googlegroups.com.



--
Jacob Christ
ProLinear/PONTECH, Inc.
+1 (909) 652-0670 Phone
http://www.pontech.com

--
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 post to this group, send email to ope...@googlegroups.com.

Matt Baker

unread,
Aug 25, 2016, 6:43:26 PM8/25/16
to OpenPnP
Semantics :)  There is positive voltage at the FET drain, negative voltage across the inductive load.
Reply all
Reply to author
Forward
0 new messages