PowerComms 1.3.0 preview
Posted by ZachHoeken
|
PowerComms 1.3.0 preview August 24, 2007 11:21PM |
Admin Registered: 17 years ago Posts: 1,487 |
Here is the first-run attempt at the 1.3.0 PowerComms PCB. the attached .zip holds PDF, GERBER, and Kicad files. there are a few things i'd like to change still:
* fatter tracks on signals. its only at 17 now, 25 is probably better.
* better silkscreen. some text isnt positioned right.
* reprap text and version. gonna be tight.
any suggestions you guys have? the LED's are positioned on each side of the Tx/Rx headers... in the same order. TTL on one side, RS232 on the other (is that the right terminology?)
i would suggest opening it in Kicad. its much easier to view, and the 3D mode is pretty rad for looking at boards. changes have been committed to SVN as well.
Edited 2 time(s). Last edit at 08/24/2007 11:23PM by Zach Hoeken.
* fatter tracks on signals. its only at 17 now, 25 is probably better.
* better silkscreen. some text isnt positioned right.
* reprap text and version. gonna be tight.
any suggestions you guys have? the LED's are positioned on each side of the Tx/Rx headers... in the same order. TTL on one side, RS232 on the other (is that the right terminology?)
i would suggest opening it in Kicad. its much easier to view, and the 3D mode is pretty rad for looking at boards. changes have been committed to SVN as well.
Edited 2 time(s). Last edit at 08/24/2007 11:23PM by Zach Hoeken.
|
Re: PowerComms 1.3.0 preview August 25, 2007 06:35AM |
Admin Registered: 17 years ago Posts: 7,879 |
Zach,
The terminology RS232 / TTL is fine. Strictly it is TTL/CMOS but TTL is shorter.
A nice placement and a good start but a few things I would change:
The TX and RX labels are the wrong way round on the schematic. P3 is received data from the last PIC in the ring. It is right on the PC layout.
The choice of 100uF for C1 seems a bit odd to me. I would go with the datasheet recommendations of 10nF ceramic close to the reg and 1uF electrolytic close to the MAX232. That is probably cheaper and will give better high frequency decoupling than a 100uF electrolytic. I would also put another 10n ceramic across the 12V rail near P9 to reduce high frequency noise coming from the PSU. If this was a commercial product you would have to comply with FCC/EN EMC regulations which would be a nightmare using a PC PSU that is intended to be operated inside a metal case.
If you move P2 and P3 so that they are in between D2 and D3 I think the association is clearer. Perhaps move D5 and D4 nearer the BD9. You can swap the resistor and LED around on the schematic if it makes layout easier. That way you could place them near to the pins they monitor.
I expect you already know this as the previous version had copper fills:
The ground track from the reg to the max could do with being a bit thicker.
The power tracks need to be much thicker. The current here can be quite high, especially if people use non standard steppers. There are lots of track width calculators on the web. The one here [www.desmith.net] reckons that for a 20C rise with 1oz copper at 6A you need tracks just over 1/4" wide. Fills are the best way to do this.
If possible it would be a good idea to leave enough clearance round the leds so that either 3mm or 5mm can be fitted. The lead pitch is the same in both cases so it gives people a bit more flexibility.
The 3D view seems to show C6 a bit bigger than its silk screen outline. If you haven't already, it would be a good idea to check this against the capacitor spec as there is not a lot of room around it.
[www.hydraraptor.blogspot.com]
The terminology RS232 / TTL is fine. Strictly it is TTL/CMOS but TTL is shorter.
A nice placement and a good start but a few things I would change:
The TX and RX labels are the wrong way round on the schematic. P3 is received data from the last PIC in the ring. It is right on the PC layout.
The choice of 100uF for C1 seems a bit odd to me. I would go with the datasheet recommendations of 10nF ceramic close to the reg and 1uF electrolytic close to the MAX232. That is probably cheaper and will give better high frequency decoupling than a 100uF electrolytic. I would also put another 10n ceramic across the 12V rail near P9 to reduce high frequency noise coming from the PSU. If this was a commercial product you would have to comply with FCC/EN EMC regulations which would be a nightmare using a PC PSU that is intended to be operated inside a metal case.
If you move P2 and P3 so that they are in between D2 and D3 I think the association is clearer. Perhaps move D5 and D4 nearer the BD9. You can swap the resistor and LED around on the schematic if it makes layout easier. That way you could place them near to the pins they monitor.
I expect you already know this as the previous version had copper fills:
The ground track from the reg to the max could do with being a bit thicker.
The power tracks need to be much thicker. The current here can be quite high, especially if people use non standard steppers. There are lots of track width calculators on the web. The one here [www.desmith.net] reckons that for a 20C rise with 1oz copper at 6A you need tracks just over 1/4" wide. Fills are the best way to do this.
If possible it would be a good idea to leave enough clearance round the leds so that either 3mm or 5mm can be fitted. The lead pitch is the same in both cases so it gives people a bit more flexibility.
The 3D view seems to show C6 a bit bigger than its silk screen outline. If you haven't already, it would be a good idea to check this against the capacitor spec as there is not a lot of room around it.
[www.hydraraptor.blogspot.com]
|
Re: PowerComms 1.3.0 preview August 25, 2007 09:54AM |
Admin Registered: 17 years ago Posts: 1,487 |
nophead Wrote:
-------------------------------------------------------
> Zach,
>
> The terminology RS232 / TTL is fine. Strictly
> it is TTL/CMOS but TTL is shorter.
yeah, and its a PCB so its hard to fit alot of text on there.
> The TX and RX labels are the wrong way round on
> the schematic. P3 is received data from the last
> PIC in the ring. It is right on the PC layout.
okay, i swapped the silkscreen text. what about the LEDs? I'd like them to be in the same order as the connectors: Rx on the left, Tx on the right
> The choice of 100uF for C1 seems a bit odd to me.
> I would go with the datasheet recommendations of
> 10nF ceramic close to the reg and 1uF electrolytic
> close to the MAX232. That is probably cheaper and
> will give better high frequency decoupling than a
> 100uF electrolytic. I would also put another 10n
> ceramic across the 12V rail near P9 to reduce high
> frequency noise coming from the PSU. If this was a
> commercial product you would have to comply with
> FCC/EN EMC regulations which would be a nightmare
> using a PC PSU that is intended to be operated
> inside a metal case.
you should bring that up with Adrian. i dont know much about electronics, but i do know enough to be able to take a design you guys come up with and lay it out on a PCB. i would suggest modifying the kicad layout, then posting the kicad schematic here, and/or emailing Adrian directly.
> If you move P2 and P3 so that they are in between
> D2 and D3 I think the association is clearer.
> Perhaps move D5 and D4 nearer the BD9. You can
> swap the resistor and LED around on the schematic
> if it makes layout easier. That way you could
> place them near to the pins they monitor.
i like that. i may have to modify the schematic to have the resistors after the bileds, would that change affect anything?
> I expect you already know this as the previous
> version had copper fills:
yup, once the design is more finalized, i'll fill on the 12v line and the Gnd line.
>
> If possible it would be a good idea to leave
> enough clearance round the leds so that either 3mm
> or 5mm can be fitted. The lead pitch is the same
> in both cases so it gives people a bit more
> flexibility.
i just measured the silkscreen on those LED's, and its .200", or 5.08mm. seems like we're good on that front.
> The 3D view seems to show C6 a bit bigger than its
> silk screen outline. If you haven't already, it
> would be a good idea to check this against the
> capacitor spec as there is not a lot of room
> around it.
will do. i checked the specs, and the capacitor we suggest has a diameter of 25mm. the silkscreen'ed circle is 24.50, so it will *just barely* peek out over that. there should be enough room, but i'll try and space out the things that are close to it a bit more.
-------------------------------------------------------
> Zach,
>
> The terminology RS232 / TTL is fine. Strictly
> it is TTL/CMOS but TTL is shorter.
yeah, and its a PCB so its hard to fit alot of text on there.
> The TX and RX labels are the wrong way round on
> the schematic. P3 is received data from the last
> PIC in the ring. It is right on the PC layout.
okay, i swapped the silkscreen text. what about the LEDs? I'd like them to be in the same order as the connectors: Rx on the left, Tx on the right
> The choice of 100uF for C1 seems a bit odd to me.
> I would go with the datasheet recommendations of
> 10nF ceramic close to the reg and 1uF electrolytic
> close to the MAX232. That is probably cheaper and
> will give better high frequency decoupling than a
> 100uF electrolytic. I would also put another 10n
> ceramic across the 12V rail near P9 to reduce high
> frequency noise coming from the PSU. If this was a
> commercial product you would have to comply with
> FCC/EN EMC regulations which would be a nightmare
> using a PC PSU that is intended to be operated
> inside a metal case.
you should bring that up with Adrian. i dont know much about electronics, but i do know enough to be able to take a design you guys come up with and lay it out on a PCB. i would suggest modifying the kicad layout, then posting the kicad schematic here, and/or emailing Adrian directly.
> If you move P2 and P3 so that they are in between
> D2 and D3 I think the association is clearer.
> Perhaps move D5 and D4 nearer the BD9. You can
> swap the resistor and LED around on the schematic
> if it makes layout easier. That way you could
> place them near to the pins they monitor.
i like that. i may have to modify the schematic to have the resistors after the bileds, would that change affect anything?
> I expect you already know this as the previous
> version had copper fills:
yup, once the design is more finalized, i'll fill on the 12v line and the Gnd line.
>
> If possible it would be a good idea to leave
> enough clearance round the leds so that either 3mm
> or 5mm can be fitted. The lead pitch is the same
> in both cases so it gives people a bit more
> flexibility.
i just measured the silkscreen on those LED's, and its .200", or 5.08mm. seems like we're good on that front.
> The 3D view seems to show C6 a bit bigger than its
> silk screen outline. If you haven't already, it
> would be a good idea to check this against the
> capacitor spec as there is not a lot of room
> around it.
will do. i checked the specs, and the capacitor we suggest has a diameter of 25mm. the silkscreen'ed circle is 24.50, so it will *just barely* peek out over that. there should be enough room, but i'll try and space out the things that are close to it a bit more.
|
Re: PowerComms 1.3.0 preview August 25, 2007 11:49AM |
Admin Registered: 17 years ago Posts: 7,879 |
ZachHoeken Wrote:
-------------------------------------------------------
> i like that. i may have to modify the schematic
> to have the resistors after the bileds, would that
> change affect anything?
No, with any two terminal network of components in series, changing the order makes no difference, the same current will always flow though them all. You just need to keep the direction of current flow through the led the same. In the case of the bi-led that is green anode closest to ground to make it green when idle, red when active.
> you should bring that up with Adrian. i dont know
> much about electronics, but i do know enough to be
> able to take a design you guys come up with and
> lay it out on a PCB. i would suggest modifying
> the kicad layout, then posting the kicad schematic
> here, and/or emailing Adrian directly.
Trust me, and the data sheets, I have attached an updated schematic with this and the LED layout change. If you make the change it is guaranteed to work as that is what the data sheets prescribe for each chip. If you don't there is a small chance the regulator could oscillate because large electrolytic capacitors don't work at high frequencies as they have significant inductance. There is no reason why the capacitor is as high as 100uF, the only thing on the 5V rail is the MAX chip and that only requires 1uF.
I don't know if this is mentioned anywhere in the wiki, but if people prefer they can build it with a MAX232A and replace all the 1uF caps with 100n ceramic which should be cheaper.
[www.hydraraptor.blogspot.com]
-------------------------------------------------------
> i like that. i may have to modify the schematic
> to have the resistors after the bileds, would that
> change affect anything?
No, with any two terminal network of components in series, changing the order makes no difference, the same current will always flow though them all. You just need to keep the direction of current flow through the led the same. In the case of the bi-led that is green anode closest to ground to make it green when idle, red when active.
> you should bring that up with Adrian. i dont know
> much about electronics, but i do know enough to be
> able to take a design you guys come up with and
> lay it out on a PCB. i would suggest modifying
> the kicad layout, then posting the kicad schematic
> here, and/or emailing Adrian directly.
Trust me, and the data sheets, I have attached an updated schematic with this and the LED layout change. If you make the change it is guaranteed to work as that is what the data sheets prescribe for each chip. If you don't there is a small chance the regulator could oscillate because large electrolytic capacitors don't work at high frequencies as they have significant inductance. There is no reason why the capacitor is as high as 100uF, the only thing on the 5V rail is the MAX chip and that only requires 1uF.
I don't know if this is mentioned anywhere in the wiki, but if people prefer they can build it with a MAX232A and replace all the 1uF caps with 100n ceramic which should be cheaper.
[www.hydraraptor.blogspot.com]
|
Re: PowerComms 1.3.0 preview August 25, 2007 03:03PM |
Admin Registered: 17 years ago Posts: 1,487 |
> > you should bring that up with Adrian. i dont
> know
> > much about electronics, but i do know enough to
> be
> > able to take a design you guys come up with and
> > lay it out on a PCB. i would suggest modifying
> > the kicad layout, then posting the kicad
> schematic
> > here, and/or emailing Adrian directly.
> Trust me, and the data sheets, I have attached an
> updated schematic with this and the LED layout
> change. If you make the change it is guaranteed to
> work as that is what the data sheets prescribe for
> each chip. If you don't there is a small chance
> the regulator could oscillate because large
> electrolytic capacitors don't work at high
> frequencies as they have significant inductance.
> There is no reason why the capacitor is as high as
> 100uF, the only thing on the 5V rail is the MAX
> chip and that only requires 1uF.
yes sir! seriously, i appreciate the way you're stepping up to this challenge. we should still run it past the rest of the team to make sure everyone is on-board, but you've proven yourself to me, so i'm willing to take your word on it.
> I don't know if this is mentioned anywhere in the
> wiki, but if people prefer they can build it with
> a MAX232A and replace all the 1uF caps with 100n
> ceramic which should be cheaper.
yup, that is mentioned in the wiki. it definitely makes it easier to construct, but unfortunately, the chip seems harder to find (and more expensive). i'll try to make it more obvious on the v1.3.0 wiki.
> know
> > much about electronics, but i do know enough to
> be
> > able to take a design you guys come up with and
> > lay it out on a PCB. i would suggest modifying
> > the kicad layout, then posting the kicad
> schematic
> > here, and/or emailing Adrian directly.
> Trust me, and the data sheets, I have attached an
> updated schematic with this and the LED layout
> change. If you make the change it is guaranteed to
> work as that is what the data sheets prescribe for
> each chip. If you don't there is a small chance
> the regulator could oscillate because large
> electrolytic capacitors don't work at high
> frequencies as they have significant inductance.
> There is no reason why the capacitor is as high as
> 100uF, the only thing on the 5V rail is the MAX
> chip and that only requires 1uF.
yes sir! seriously, i appreciate the way you're stepping up to this challenge. we should still run it past the rest of the team to make sure everyone is on-board, but you've proven yourself to me, so i'm willing to take your word on it.
> I don't know if this is mentioned anywhere in the
> wiki, but if people prefer they can build it with
> a MAX232A and replace all the 1uF caps with 100n
> ceramic which should be cheaper.
yup, that is mentioned in the wiki. it definitely makes it easier to construct, but unfortunately, the chip seems harder to find (and more expensive). i'll try to make it more obvious on the v1.3.0 wiki.
|
Anonymous User
Re: PowerComms 1.3.0 preview August 26, 2007 04:42PM |
I know I'm chiming in a bit late here, but would there be any interest in putting a JDM2 programmer on-board? Originally I wanted to have a self-powered programmer on-board that worked with standard programming software, but every attempt I made at that seemed way too complex or just didn't work. Just putting a JDM on the board would probably be good enough for most people, and it would buy us some time until we can do it right in 2.0.
It looks like it would cost 1 to 1.5 square inches of board space for the programmer and header, maybe a little more depending on how things are arranged. The components would run another $1.50 or so. Is this worth trying?
Also, when I was updating my eagle schematics that the numbering still looks like it's backwards on the polarized headers. The pin that's numbered 1 in the schematic and marked with a square pad on the board winds up being the last pin if you insert the header according to the silk screen. It's not a problem as long as you know to follow the silk screen. I guess the Ki-cad library just has the pins reversed?
It looks like it would cost 1 to 1.5 square inches of board space for the programmer and header, maybe a little more depending on how things are arranged. The components would run another $1.50 or so. Is this worth trying?
Also, when I was updating my eagle schematics that the numbering still looks like it's backwards on the polarized headers. The pin that's numbered 1 in the schematic and marked with a square pad on the board winds up being the last pin if you insert the header according to the silk screen. It's not a problem as long as you know to follow the silk screen. I guess the Ki-cad library just has the pins reversed?
|
Re: PowerComms 1.3.0 preview August 26, 2007 05:31PM |
Admin Registered: 17 years ago Posts: 1,487 |
i'm definitely interested in that. i dont know much about how you would go about implementing that change, but it seems like it might be rather experimental, and would require a good amount of testing. the v1.3 board seems to be at a stable point right now, so i'd like to get a test-run of it out to the manufacturers this week or next week.
i think the best route would be for you to start working on the JDM programmer integration. that way you'll have a good couple of months to really hammer away at it, and get it working really well. if you get a working version up and running, we'll definitely include it in whatever the next version of the board happens to be. then again, if you crank out a working design in the next week or so... i'd love to include it!
as for the polarized headers, i made the footprints on them, so i probably just messed up the silkscreen. would you mind elaborating on what the proper orientation / pin layout is on those?
Edited 1 time(s). Last edit at 08/26/2007 05:47PM by Zach Hoeken.
i think the best route would be for you to start working on the JDM programmer integration. that way you'll have a good couple of months to really hammer away at it, and get it working really well. if you get a working version up and running, we'll definitely include it in whatever the next version of the board happens to be. then again, if you crank out a working design in the next week or so... i'd love to include it!
as for the polarized headers, i made the footprints on them, so i probably just messed up the silkscreen. would you mind elaborating on what the proper orientation / pin layout is on those?
Edited 1 time(s). Last edit at 08/26/2007 05:47PM by Zach Hoeken.
|
Re: PowerComms 1.3.0 preview August 26, 2007 08:23PM |
Registered: 16 years ago Posts: 235 |
I have absolutely no idea how hard this would be from an electronics point of view but I'll just put it out there to get shot down anyway:
The power would be better if it alternated G +12 G +12 so that you can use 2pin headers and connectors and easily swap out faulty power leads and it also makes them easier to keep track of and less wire tangle as well.
In my case I've made them from 2 different color wires to keep track of them but if they were paired then you wouldn't have so much difficulty and just take two wires sitting side by side, working your way from one end to the other.
Also, there is currently an unused pair i.e. the powercomms board has power connections for 6 devices but the current design only calls for 5. This also complicates matters in the current design and I hade to redo a couple of my wires as they were the wrong color for the holes they were plugged into due to miscounting.
If this is a rational choice for later expansion then it should be left in. If its just because of price/availability of 12 pin header/connector vs. 10 pin then scrap it and go with 5x2pin if the circuit tracing is easy enough to change.
Just my uninformed opinion :-)
Edited 1 time(s). Last edit at 08/26/2007 08:24PM by reece.arnott.
The power would be better if it alternated G +12 G +12 so that you can use 2pin headers and connectors and easily swap out faulty power leads and it also makes them easier to keep track of and less wire tangle as well.
In my case I've made them from 2 different color wires to keep track of them but if they were paired then you wouldn't have so much difficulty and just take two wires sitting side by side, working your way from one end to the other.
Also, there is currently an unused pair i.e. the powercomms board has power connections for 6 devices but the current design only calls for 5. This also complicates matters in the current design and I hade to redo a couple of my wires as they were the wrong color for the holes they were plugged into due to miscounting.
If this is a rational choice for later expansion then it should be left in. If its just because of price/availability of 12 pin header/connector vs. 10 pin then scrap it and go with 5x2pin if the circuit tracing is easy enough to change.
Just my uninformed opinion :-)
Edited 1 time(s). Last edit at 08/26/2007 08:24PM by reece.arnott.
|
Re: PowerComms 1.3.0 preview August 26, 2007 10:28PM |
Admin Registered: 17 years ago Posts: 1,487 |
|
Re: PowerComms 1.3.0 preview August 27, 2007 04:19AM |
Admin Registered: 17 years ago Posts: 7,879 |
Yes I was thinking the same thing but I didn't suggest it because I thought having two different power pin outs is bound to lead to somebody getting it wrong and letting the smoke out their other boards.
I suppose as long as it is clear on the silkscreen and so is the board version and the wiki instructions are board specific then it should be OK.
[www.hydraraptor.blogspot.com]
I suppose as long as it is clear on the silkscreen and so is the board version and the wiki instructions are board specific then it should be OK.
[www.hydraraptor.blogspot.com]
|
Re: PowerComms 1.3.0 preview August 27, 2007 09:35AM |
Admin Registered: 17 years ago Posts: 177 |
Yes - I think that using alternating G + would be good. We can minimise the chance of errors by making the gap between each power pair != 2.54 mm and by using the one-way-round keyed connectors that we've used elsewhere.
We must keep the spare connector for power in addition to the 5 the RepRap machine itself uses - we use it all the time for plugging extra controller boards in on the bench for testing.
Zach - he say:
"also, emf is interested in doing the programmer stuff. i'm pretty sure that
we're all in agreement that it would be a very useful addition to the
powercomms board. i'd like to get the v1.3 board out to people sooner
rather than later, to make it easier to debug the whole process. my guess
is we will probably be ready to order a test batch sometime next week."
I'm obviously losing it - I thought we were going for in-circuit programming on the controller boards. Why a programmer on the power-comms board too?
best wishes
Adrian
[reprap.org]
[reprapltd.com]
We must keep the spare connector for power in addition to the 5 the RepRap machine itself uses - we use it all the time for plugging extra controller boards in on the bench for testing.
Zach - he say:
"also, emf is interested in doing the programmer stuff. i'm pretty sure that
we're all in agreement that it would be a very useful addition to the
powercomms board. i'd like to get the v1.3 board out to people sooner
rather than later, to make it easier to debug the whole process. my guess
is we will probably be ready to order a test batch sometime next week."
I'm obviously losing it - I thought we were going for in-circuit programming on the controller boards. Why a programmer on the power-comms board too?
best wishes
Adrian
[reprap.org]
[reprapltd.com]
|
Anonymous User
Re: PowerComms 1.3.0 preview August 27, 2007 09:50AM |
ZachHoeken Wrote:
-------------------------------------------------------
> i'm definitely interested in that. i dont know
> much about how you would go about implementing
> that change, but it seems like it might be rather
> experimental, and would require a good amount of
> testing.
It's about a dozen new components, but it should only touch the existing circuitry in one place (the TXD pin). We might need to isolate that pin with a SPDT switch or jumper, as I'm not sure if the MAX232 and LED will suck too much current from the programmer.
Actually, it'll also break the loopback connections on RTS/CTS and DSR/DTR. I've always left those pins unconnected and I've never had a problem, so I'm having a hard time getting too worried about this.
I'll cook up a board tonight and see if there are any surprises.
-------------------------------------------------------
> i'm definitely interested in that. i dont know
> much about how you would go about implementing
> that change, but it seems like it might be rather
> experimental, and would require a good amount of
> testing.
It's about a dozen new components, but it should only touch the existing circuitry in one place (the TXD pin). We might need to isolate that pin with a SPDT switch or jumper, as I'm not sure if the MAX232 and LED will suck too much current from the programmer.
Actually, it'll also break the loopback connections on RTS/CTS and DSR/DTR. I've always left those pins unconnected and I've never had a problem, so I'm having a hard time getting too worried about this.
I'll cook up a board tonight and see if there are any surprises.
|
Re: PowerComms 1.3.0 preview August 27, 2007 10:17AM |
Admin Registered: 17 years ago Posts: 1,487 |
> "also, emf is interested in doing the programmer
> stuff. i'm pretty sure that
> we're all in agreement that it would be a very
> useful addition to the
> powercomms board. i'd like to get the v1.3 board
> out to people sooner
> rather than later, to make it easier to debug the
> whole process. my guess
> is we will probably be ready to order a test batch
> sometime next week."
>
> I'm obviously losing it - I thought we were going
> for in-circuit programming on the controller
> boards. Why a programmer on the power-comms board
> too?
it was definitely discussed in the electronics forums a while back, and the general reaction was positive. here's a short rundown of the reasons:
1. we already have serial comms, and this way, reprap can program itself. the entire chain can be open source. no more proprietary software and/or commercial boards needed
2. it only adds a little bit more complexity, and then we dont have to recommend an external programmer
3. it will be an easier workflow... reprap is already connected to the serial port.
no more of this: unplug reprap. plug in serial programmer. remove chip from reprap, insert into programmer, remove from programmer, insert into universal board, unplug programer, plug reprap back in.
instead it can become this: plug ICSP cable from powercomms board to board to program. program board. unplug icsp header.
theres no harm in trying. if Eric can come up with a design, as he seems confident of, then i see no reason not to include it.
> stuff. i'm pretty sure that
> we're all in agreement that it would be a very
> useful addition to the
> powercomms board. i'd like to get the v1.3 board
> out to people sooner
> rather than later, to make it easier to debug the
> whole process. my guess
> is we will probably be ready to order a test batch
> sometime next week."
>
> I'm obviously losing it - I thought we were going
> for in-circuit programming on the controller
> boards. Why a programmer on the power-comms board
> too?
it was definitely discussed in the electronics forums a while back, and the general reaction was positive. here's a short rundown of the reasons:
1. we already have serial comms, and this way, reprap can program itself. the entire chain can be open source. no more proprietary software and/or commercial boards needed
2. it only adds a little bit more complexity, and then we dont have to recommend an external programmer
3. it will be an easier workflow... reprap is already connected to the serial port.
no more of this: unplug reprap. plug in serial programmer. remove chip from reprap, insert into programmer, remove from programmer, insert into universal board, unplug programer, plug reprap back in.
instead it can become this: plug ICSP cable from powercomms board to board to program. program board. unplug icsp header.
theres no harm in trying. if Eric can come up with a design, as he seems confident of, then i see no reason not to include it.
|
Re: PowerComms 1.3.0 preview August 27, 2007 10:47AM |
Admin Registered: 17 years ago Posts: 1,915 |
I've wondered for a long time just what an internal programmer board to the project achieves. The presumption, I guess, is that a lot of people are going to be tinkering with the firmware, a situation that I don't think is actually happening to any great extent.
Given that the cost of a 16F628 and the like is under $2 doesn't it make sense to just stock the PIC chips in the foundation and sell them preprogrammed? I know eventually that the boards will be redesigned to use a more sophisticated PIC that will allow them to be programmed over the serial loop without needing a programmer at all. Because of that, it seems like all the light and heat surrounding the programmer board is wasting energy that would be better used on other parts of the reprap development project.
Just my opinion, mind.
Given that the cost of a 16F628 and the like is under $2 doesn't it make sense to just stock the PIC chips in the foundation and sell them preprogrammed? I know eventually that the boards will be redesigned to use a more sophisticated PIC that will allow them to be programmed over the serial loop without needing a programmer at all. Because of that, it seems like all the light and heat surrounding the programmer board is wasting energy that would be better used on other parts of the reprap development project.
Just my opinion, mind.
|
Re: PowerComms 1.3.0 preview August 27, 2007 11:01AM |
Registered: 16 years ago Posts: 370 |
Forrest Higgs Wrote:
-------------------------------------------------------
> Given that the cost of a 16F628 and the like is
> under $2 doesn't it make sense to just stock the
> PIC chips in the foundation and sell them
> preprogrammed?
At this stage in the project while it is true that most people won't be tinkering with the firmware themselves (although many will be, I think!) the official firmware is still being modified on a semi-regular basis. Without a programmer of some type, the early adopters of RepRap would have no way to upgrade to the latest offering, which presumably is an improvement on what came before. They would also be stuck with a certain version of the host software, because changes in the firmware often require tweaks to the host software package as well that would break it without the updated firmware.
If RepRap ever reaches a developmental plateau (perhaps once 1.0 is released?) it may make sense to sell pre-flashed chips. Then again, once 1.0 is out everyone will be getting their Darwin parts from other people with darwins, who got them from other people with darwins, and presumably if you follow the chain up far enough (hopefully only 1 or 2 levels) you'll find someone with a programmer who is willing to program your PICs for you and, ostensibly, is in your geographical area.
Kyle
-------------------------------------------------------
> Given that the cost of a 16F628 and the like is
> under $2 doesn't it make sense to just stock the
> PIC chips in the foundation and sell them
> preprogrammed?
At this stage in the project while it is true that most people won't be tinkering with the firmware themselves (although many will be, I think!) the official firmware is still being modified on a semi-regular basis. Without a programmer of some type, the early adopters of RepRap would have no way to upgrade to the latest offering, which presumably is an improvement on what came before. They would also be stuck with a certain version of the host software, because changes in the firmware often require tweaks to the host software package as well that would break it without the updated firmware.
If RepRap ever reaches a developmental plateau (perhaps once 1.0 is released?) it may make sense to sell pre-flashed chips. Then again, once 1.0 is out everyone will be getting their Darwin parts from other people with darwins, who got them from other people with darwins, and presumably if you follow the chain up far enough (hopefully only 1 or 2 levels) you'll find someone with a programmer who is willing to program your PICs for you and, ostensibly, is in your geographical area.
Kyle
|
Anonymous User
Re: PowerComms 1.3.0 preview August 27, 2007 11:52AM |
Forrest Higgs Wrote:
-------------------------------------------------------
> I've wondered for a long time just what an
> internal programmer board to the project achieves.
> The presumption, I guess, is that a lot of people
> are going to be tinkering with the firmware, a
> situation that I don't think is actually happening
> to any great extent.
To some extent, I agree it's a bit silly. I don't see any compelling reason to merge a PIC programmer into the project, it seems perfectly reasonable to list it as a required tool and let people buy their own. The last time this was brought up, my opinion was in the minority. I guess everyone is going to interpret "self-replicating" a bit differently.
On the other hand, it's cheap to add it (assuming it works), so maybe that alone justifies incorporating it. It seems like at least a few people have been following the instructions on the wiki for building the PIC programmers, so maybe there's a bigger need than I'm imagining. I really don't feel strongly one way or another on it...
Right now, I don't think we could get away with just selling pre-programmed PICs. It sounds like there are still some firmware changes in the pipeline, so anyone that bought pre-programmed PICs would do that with the expectation that they'll need to buy a new set of PICs later. It might make sense economically, but it just doesn't feel right.
-------------------------------------------------------
> I've wondered for a long time just what an
> internal programmer board to the project achieves.
> The presumption, I guess, is that a lot of people
> are going to be tinkering with the firmware, a
> situation that I don't think is actually happening
> to any great extent.
To some extent, I agree it's a bit silly. I don't see any compelling reason to merge a PIC programmer into the project, it seems perfectly reasonable to list it as a required tool and let people buy their own. The last time this was brought up, my opinion was in the minority. I guess everyone is going to interpret "self-replicating" a bit differently.
On the other hand, it's cheap to add it (assuming it works), so maybe that alone justifies incorporating it. It seems like at least a few people have been following the instructions on the wiki for building the PIC programmers, so maybe there's a bigger need than I'm imagining. I really don't feel strongly one way or another on it...
Right now, I don't think we could get away with just selling pre-programmed PICs. It sounds like there are still some firmware changes in the pipeline, so anyone that bought pre-programmed PICs would do that with the expectation that they'll need to buy a new set of PICs later. It might make sense economically, but it just doesn't feel right.
|
Re: PowerComms 1.3.0 preview August 27, 2007 12:02PM |
Admin Registered: 17 years ago Posts: 1,487 |
also, on a personal note... i did stock pre-programmed chips at one point in time, but it was a big time-eater. not to mention i dont fully trust myself to program every chip correctly, every time. its much better for each person to have the capability to program their own chips.
it doesnt make alot of sense to have a fully open source project and then be like... use this proprietary system to program an essential part of your machine. if we can modify a board to do that, and have everything be nice and integrated, then i'm all for it. of course this is still a temporary fix until we get the software programming stuff on the v2.0 board. even then though, we'll need a way to get the intial firmware on the boards. i think its a very useful and valuable addition.
also, i dont really consider it wasted energy... its an open source project, so that means we cant assign things to people, or force them to work on something. if someone is interested in working on a certain aspect, then the best thing we can do is to encourage them. otherwise they might decide they're not interested and move on completely, which would be a huge bummer. any energy or interest is good.
it doesnt make alot of sense to have a fully open source project and then be like... use this proprietary system to program an essential part of your machine. if we can modify a board to do that, and have everything be nice and integrated, then i'm all for it. of course this is still a temporary fix until we get the software programming stuff on the v2.0 board. even then though, we'll need a way to get the intial firmware on the boards. i think its a very useful and valuable addition.
also, i dont really consider it wasted energy... its an open source project, so that means we cant assign things to people, or force them to work on something. if someone is interested in working on a certain aspect, then the best thing we can do is to encourage them. otherwise they might decide they're not interested and move on completely, which would be a huge bummer. any energy or interest is good.
|
Re: PowerComms 1.3.0 preview August 28, 2007 04:59PM |
Admin Registered: 17 years ago Posts: 177 |
Zach the Knower of All Things, he say:
> instead it can become this: plug ICSP cable from powercomms board to board to
> program. program board. unplug icsp header.
Ah! Yes, I obviously was (am) losing it. If I'd thought for a bit I might have found it again....
That is indeed exactly what we want. V. useful indeed.
best wishes
Adrian
[reprap.org]
[reprapltd.com]
> instead it can become this: plug ICSP cable from powercomms board to board to
> program. program board. unplug icsp header.
Ah! Yes, I obviously was (am) losing it. If I'd thought for a bit I might have found it again....
That is indeed exactly what we want. V. useful indeed.
best wishes
Adrian
[reprap.org]
[reprapltd.com]
|
Anonymous User
Re: PowerComms 1.3.0 preview August 29, 2007 01:15AM |
I cooked up a board that's equivalent to Zach's 1.3.0 with a JDM2 programmer on-board. The initial results are good, everything works pretty much as advertised. I've put in a mechanical switch on the TX signal to switch between programming and communicating. I'm experimenting with trying to get rid of the switch, but I have a hunch it's going to be required from watching the LEDs dim when I short it out. The bicolor LEDs glow dimly, but are visible enough. It's pretty hard to see the pulses when transmitting with my configuration -- green/red LEDs with green glowing in the idle state. You *can* see it though, which is all we really need. The single-color LEDs on the other side of the 232 are plenty bright. I'll do some more testing tomorrow.
BTW, almost all the parts I used were from Futurlec, so the BOM generator's Futurlec part numbers are good as far as the PowerComms board goes.
BTW, almost all the parts I used were from Futurlec, so the BOM generator's Futurlec part numbers are good as far as the PowerComms board goes.
|
Re: PowerComms 1.3.0 preview August 29, 2007 04:14AM |
Admin Registered: 17 years ago Posts: 7,879 |
Separate red and green might be easier to see. Especially for people with red green colour blindness!
[www.hydraraptor.blogspot.com]
[www.hydraraptor.blogspot.com]
|
Re: PowerComms 1.3.0 preview August 29, 2007 09:29AM |
Admin Registered: 17 years ago Posts: 1,487 |
nophead Wrote:
-------------------------------------------------------
> Separate red and green might be easier to see.
> Especially for people with red green colour
> blindness!
are you recommending that we move away from bicolor LEDs, or that we possibly do it in the future. the board is pretty full right now, so this change would be a pain in the butt.
perhaps part of the debugging instructions for those who cant get the RS232 stuff to work will be 'turn off the lights in the room...' as well as getting a non-color blind friend to help out...
if you really think we should make the change, i'll do it, but i'd rather move on to other things.
-------------------------------------------------------
> Separate red and green might be easier to see.
> Especially for people with red green colour
> blindness!
are you recommending that we move away from bicolor LEDs, or that we possibly do it in the future. the board is pretty full right now, so this change would be a pain in the butt.
perhaps part of the debugging instructions for those who cant get the RS232 stuff to work will be 'turn off the lights in the room...' as well as getting a non-color blind friend to help out...
if you really think we should make the change, i'll do it, but i'd rather move on to other things.
|
Re: PowerComms 1.3.0 preview August 29, 2007 11:04AM |
Admin Registered: 17 years ago Posts: 7,879 |
Well emf does say the red is visible so we can probably stick with what we have got.
I haven't seen it with the actual comms packets you are using so I think the call needs to be made by somebody that has.
It would be a shame to go to separate leds after all the hassle we hade with the bi-led symbol!
[www.hydraraptor.blogspot.com]
I haven't seen it with the actual comms packets you are using so I think the call needs to be made by somebody that has.
It would be a shame to go to separate leds after all the hassle we hade with the bi-led symbol!
[www.hydraraptor.blogspot.com]
|
Re: PowerComms 1.3.0 preview August 29, 2007 11:51AM |
Admin Registered: 17 years ago Posts: 1,487 |
i agree. plus those bi-led's are pretty nifty. i think it will make our boards look really cool.
i cant wait to have a reprap board with lots of blinking lights running. since it appears that the board is working properly with the new changes, i'll finish up the cosmetic changes, order a test batch from gold phoenix, and then send them out to those who are interested.
send me a PM or post here if you'd like one. if you promise to any (or all) of the following, i'll send you a free PCB: a) take build pictures, b) document the build in the wiki, c) submit bug reports, or d) have helped with the design process.
of course, donations to cover shipping and the boards themselves are always welcome...
thanks a bunch guys!
i cant wait to have a reprap board with lots of blinking lights running. since it appears that the board is working properly with the new changes, i'll finish up the cosmetic changes, order a test batch from gold phoenix, and then send them out to those who are interested.
send me a PM or post here if you'd like one. if you promise to any (or all) of the following, i'll send you a free PCB: a) take build pictures, b) document the build in the wiki, c) submit bug reports, or d) have helped with the design process.
of course, donations to cover shipping and the boards themselves are always welcome...
thanks a bunch guys!
|
Anonymous User
Re: PowerComms 1.3.0 preview August 29, 2007 12:07PM |
I think it's ok as-is. If it were our only status indicator, it might be worth re-designing, but since it's only really going to be used to diagnose some pretty rare connection problems, I think it's fine. We can probably design software tests that will make it more visible -- flood the serial port with 0xff or 0x00 to make one color dominate over the other. It could just be some quirk of the LED I had on hand too.
The new PCB design is looking good.
The new PCB design is looking good.
|
Re: PowerComms 1.3.0 preview August 29, 2007 01:02PM |
Admin Registered: 17 years ago Posts: 7,879 |
Yes the red green balance does vary a lot with different makes of BILED. We had a device in production for many years which we occasionally deliberately fed with 50/50 duty cycle to get orange. We it got outsourced to Malaysia they substituted a different LED without approval. Red and green look fine but the orange mode is indistinguishable from red.
[www.hydraraptor.blogspot.com]
[www.hydraraptor.blogspot.com]
|
Anonymous User
Re: PowerComms 1.3.0 preview August 29, 2007 05:05PM |
a good part of the review package would be the parts list. Just so things like capacitor voltage ratings (would be nice on the schematic too but not absolutely necessary). For instance what part number are the bicolor leds?
Nopheads capacitor suggestions are good (vote of confidence from an Electrical Engineer).
The 78L05 is only has class 1 (1kV) ESD protection. Since the 12V input to that chip is an external connection some additional protection might prevent someone from zapping the chip some dry day. I would recommend at least class 3 (3kV) protection for something that will be handled quite often.
If a TVS diode was added between 12v input and gnd it would protect the 78l05 nicely.
Example part:
[www.mouser.com]
$0.22
Didnt get a chance to look at the layout too much still learning kicad.
[edit] added an updated version of the schematic with the diode placed (unfortunately I did not create the correct symbol).
The chosen TVS diode has a reverse breakdown voltage between 14.3 and 15.8, outside our working voltage and should do a pretty good job of preventing damage to the 78L05.
[edit2] PS nice work Zach, thanks for the hard work.
Edited 2 time(s). Last edit at 08/29/2007 05:19PM by d0ubled.
Nopheads capacitor suggestions are good (vote of confidence from an Electrical Engineer).
The 78L05 is only has class 1 (1kV) ESD protection. Since the 12V input to that chip is an external connection some additional protection might prevent someone from zapping the chip some dry day. I would recommend at least class 3 (3kV) protection for something that will be handled quite often.
If a TVS diode was added between 12v input and gnd it would protect the 78l05 nicely.
Example part:
[www.mouser.com]
$0.22
Didnt get a chance to look at the layout too much still learning kicad.
[edit] added an updated version of the schematic with the diode placed (unfortunately I did not create the correct symbol).
The chosen TVS diode has a reverse breakdown voltage between 14.3 and 15.8, outside our working voltage and should do a pretty good job of preventing damage to the 78L05.
[edit2] PS nice work Zach, thanks for the hard work.
Edited 2 time(s). Last edit at 08/29/2007 05:19PM by d0ubled.
|
Re: PowerComms 1.3.0 preview August 29, 2007 05:22PM |
Admin Registered: 17 years ago Posts: 7,879 |
I think the decoupling capacitors will protect the 78L05 from any static discharge. The charge is divided by the ratio of the capacitor to the capacitance of the human body which is probably at least 1000:1 for the 100n caps. I have protected much more vulnerable things like MOSFETs from a direct strike off a piezo with just a 10n ceramic cap. I only use TVS diodes on things that can't have extra capacitance, and only on commercial products to meet regs. I have never had problems with stuff at home. Mind you it does depend on what you wear and the local climate.
[www.hydraraptor.blogspot.com]
[www.hydraraptor.blogspot.com]
|
Anonymous User
Re: PowerComms 1.3.0 preview August 29, 2007 05:29PM |
|
Re: PowerComms 1.3.0 preview August 29, 2007 05:36PM |
Admin Registered: 17 years ago Posts: 7,879 |
Yes I had already suggested a small cap across the 12V rail but I just noticed it hasn't made it to the latest version. Both 100n would be fine if is reduces the bom lines.
[www.hydraraptor.blogspot.com]
[www.hydraraptor.blogspot.com]
|
Anonymous User
Re: PowerComms 1.3.0 preview August 29, 2007 05:37PM |
[nophead] Ahh got it, was wondering if you were referring to the 4700uF as the "decoupling" cap 
.
Also. Why are we using a 50V capacitor on a 12V input? It costs $3.17 at mouser where a 25V part (still over 50% derating) costs $1.69 and is about half as wide.
Beyond this, why a 4700uF? Extra noise suppression for the downstream stepper motors?
Edited 2 time(s). Last edit at 08/29/2007 05:41PM by d0ubled.
. Also. Why are we using a 50V capacitor on a 12V input? It costs $3.17 at mouser where a 25V part (still over 50% derating) costs $1.69 and is about half as wide.
Beyond this, why a 4700uF? Extra noise suppression for the downstream stepper motors?
Edited 2 time(s). Last edit at 08/29/2007 05:41PM by d0ubled.
Sorry, only registered users may post in this forum.