OpenPNP on 48VB - but which route?

[vespaman]

Hi all,

I picked up a moderately used 48VB a few days ago, that I intend to use for smaller batches and prototype work. I mainly use 0402, and therefore, I have decided to skip learning the Charmhigh firmware and its issues, and instead go directly to OpenPnP.

Now, the previous owner intended to switch to Open PnP also, so I got with the 48VB, also a Smoothie board (v1.1), the two USB cameras that are recommended and a drag chain.

So I should be good to go.

First off, I figured that I should simply use the 48VB mainboard, so I have ordered a USB-422 (isolated, which is not needed I have since learned, since the onboard 422 is already isolated) from Mouser.

But today, I started to think that maybe it is as good (or better?) to use the smoothie board, since it is anyway just laying in front of me.

It can never be bad to be able to go back to Charmhigh, that is the only real benefit I can see with the smoothie board route. Also I read about comm's issues on the Chmt mainboards, but that is primarily with the RS232 I think(?).

So -  My question to you; which solution should you have gone with? Is there any benefits with one over the other? Can the smoothie board do everything the Chmt mainboard can, or is it even better? Performance?

[Jan]

Hi vespaman!
This is just my personal view: I converted my CHM-T a few week before
to the OpenPnp and never looked back. I'm using the RS232 cable that
comes with the machine and never had com issues. It's likely primarily a
ground and configuration issue: keep the connection isolated and enable
"Confirmation Flow Control?" is my recommendation.
In addition, I'd recommend to use the latest OpenPnp testing version.
It contains a few enhancement in the Issues & Solutions systems that
especially target the Charmhigh machines.
Concerning the controller board: a few weeks before Wayne reported
about his progress in replacing the mainboard with a Duet. He's probably
the one for the most qualified response. From my understanding
Smoothieware v1.1 uses a LPC1768 which is quite slow and has less ram
compared to the STM32F407 of the original controller board. Hence you
might have more performance with the original board. Next, as Wayne
reported, there is 7V supply needed at the head, IIRC for the vacuum
sensors. You'd have to generate that yourself if you replace the board.
Once you decided how to continue here are few points I learned and like
to put into the Wiki but did not yet found the time to do that:
- the drag pin will burn if operated for more then a few seconds at
100%. If operated using a PWM signal it can be switched to ~10% holding
current after enabling and then keeps cool over longer periods.
- the blower will burn out if operated over a longer time at 100% (can
on a hours/days scale). The original firmware operates it at 2% using a
16kHz pwm.
- the vacuum pump is operated at 50% by the original software using a
16kHz pwm.
- It is recommended by openpnp programmers, that the peelers are
operated as separate axis, hence smoothieware should be compiled using
PAXIS=7. (IIRC thats not supported by the original LPC based code due to
memory constraints.)
- The homing direction and the parking position are in the opposite
corners, hence I'd make sure soft limits on the axis are configured
conservatively and/or automatic park after home is disabled. Otherwise
the machine might crash when homed. (It's less likely for a 48VB as its
larger compared to the 36VA).
- the machine.xml by Matt Backer is not compatible with OpenPnp v2.x.
You'll find config files from others here in the list. (You can also
have mine, even if its for a 36VA.)
I've modified the smoothieware port firmware for the original
controller board to my findings. It's in beta state currently and I'll
publish it when I've more time... If you like to try it, please let me
know, then I'll send you a copy. Please keep in mind, that I have no48VB
to test with.

Jan

> --
> You received this message because you are subscribed to the Google
> Groups "Desktop Pick and Place" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to desktop-pick-and-...@googlegroups.com
> <mailto:desktop-pick-and-...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/desktop-pick-and-place/058185ae-a8b0-4f15-b3ad-cbd8640f18ecn%40googlegroups.com
> <https://groups.google.com/d/msgid/desktop-pick-and-place/058185ae-a8b0-4f15-b3ad-cbd8640f18ecn%40googlegroups.com?utm_medium=email&utm_source=footer>.

[mark maker]

Hi vespaman

I'm not sure but doesn't the 48VB have two sides with feeders? If so, it needs 7 axes (two peelers), and as Jan has already pointed out, a Smoothieboard can only control 6 axes.

Jan/vespaman can you please explain what the options are with the mentioned USB-422 vs RS232? Is that a difference between models 48 and 36? Do any of them support proper serial flow control? Because AFAIK that's the only real sore point with using the built-in board.

_Mark

[vespaman]

Hi Mark,

Yes, the 48VB has to sides with feeders. So I suppose that kind of makes the decision easier for me.. :)

So I only have (very limited, mind you!) knowledge about the 48, which has the 422 interface populated. The interface is using a ADM2587E isolation RS422 interface IC. This IC is specified to cope with up to 500kbps, so I think we can forget to go beyond that. It would be possible to change to another version of the IC, which goes much faster (and is pin compatible). But I guess that 480kb/s should be enough for now.

RS422 does not do separate hardware handshaking. However XON/XOFF should be possible, I suppose? That would also be working with the RS232 interface of the 36. But maybe you have considered this, already?

I can't really see any reason for the original board not to do comm's well enough. I have not looked into the (ported) smoothie code though. Is it available somewhere (git or download or something)?

Thanks,

  Micael

[black...@blackboxembedded.com]

Excellent insights made by Jan, so read and re read his comments carfully.

I can only share my exp on the 36VA. The 36 and 48 use the same base mainboard, but the 48 uses 422 hardware and the 36 uses 232. 

On my 36 using OEM mainboard w the Smoothie port I had comm issues (message garbling), that others don't seem to suffer. This may have been my doing as...

-I basically tore the machine electronics apart to ohm things out. This is not necc as there is a accurate pinout on the sparkfun site.

- I relocated the 232 connector from the rear of the machine to the front and in doing so may have disrupted the OEM grounding scheme. The markings on the mainboard and camera board show 'PE' for earth ground for the 232 xcvr and camera switch board, though I measured them common to 'GND' . Lastly on the 36 there is x2 232 ports, one for debug and the other for control. I may have gotten these crossed.

I chose to go to a better understood control board and chose Duet. Things to note about going to a different controller...

-Expensive if you want to keep the XY encoding. The OEM board has onboard encoding that you will either have to forego or replace with off board drivers. I chose the later.

-Expensive if you want to keep OEM 36V+ for the motors, Duet limit is 32V. I chose offboard drivers w encoders that lets me run 48V

-You'll need to add a 7V supply.

Otherwise its pretty straightforward so long as th control board you choose has 24V tolerant input/outputs.

Ill do a conversion thread down the road

[vespaman]

Hi Jan,

So this is the third time I write this - my first reply was deleted, this will be short version.

So I guess I will go for the original board - the memory issue in particular does not bode well and I will want both feeders working properly in the end anyway.

Also I suspect that will be the only way to, at some point in time go closed loop on the steppers(?).

I would very much like to test your firmware - the idea of burned pumps an broken drag pins does not resonate too well with me... :-)

I think the whole compatibility chain (36 vs 48 vs openpnp config file versions vs firmware this and that) is _really_ hard to follow. Especially since there's not one source, and no linear versioning (afict).

So, if anyone has a config file for the 48 and Jan's FW and openpnp 2.x I'd really appreciate it!

Let's see if this message makes it... :-o

Thanks,

 Micael

[Jan]

As far as I know, the controler boards are the same, they are just
differently populated. For the 48 the RS422 is populated and the RS232
not. The 36 has the RS232 populated and the RS422 not. Both usarts are
enabled in Matts original port, hence one can use which ever one wonts.
The RS232 uses a four channel RS232 level shifter. All four channels are
connected via optos to the MCU and to connectors on the edge of the PCB.
Each two channels are connected such, that they can be used as hardware
usart. If I understand the setup and pcb marking correctly, one port was
intended for communication and the other for debug output. In theory it
should be possible to use the two spare lines for RTS/CTS hardware
handshake. An even better solution would be to remove the RS232 level
shifter and connect a RS232-TTL converter directely to the optos. This
would allow for faster serial speed (currently limited by the level
shifter) and simplify the power supply situation for the isolated side
of the optos. (The required 5V is currently generated on the camera
switcher board. But thats a 36 only problem...)
There is also an option to add USB serial to the MCU. The pins are
available via the CAN connector but the software changes would be large...

Jan

> https://groups.google.com/d/msgid/desktop-pick-and-place/b9c56c7b-4d7b-7c85-2bf5-31e752fe51e7%40makr.zone
> <https://groups.google.com/d/msgid/desktop-pick-and-place/b9c56c7b-4d7b-7c85-2bf5-31e752fe51e7%40makr.zone?utm_medium=email&utm_source=footer>.

[Jan]

This message made it!
Please find my latest .hex file attached as well as my machine.xml. I
expect that it will get you going quickly with respect to the left side
feeders.
For the right side, the motor is configured as an other axis. I assume
you'll have to clone the PEELER and change the gcode axis letter from C
to D.
I've adjusted the steps/mm values for X and Y in the ENABLE_COMMAND.
Please make sure to reopen all solved and dismissed entries in Issues &
Solutions to get maximum support in calibrating your machine.
If you have any other question, please ask!

Jan

>>> <https://groups.google.com/d/msgid/desktop-pick-and-place/058185ae-a8b0-4f15-b3ad-cbd8640f18ecn%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> <https://groups.google.com/d/msgid/desktop-pick-and-place/058185ae-a8b0-4f15-b3ad-cbd8640f18ecn%40googlegroups.com?utm_medium=email&utm_source=footer>.

>>>
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Desktop Pick and Place" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to desktop-pick-and-...@googlegroups.com
> <mailto:desktop-pick-and-...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/desktop-pick-and-place/bf154ba4-6f21-4cfc-937f-37bff819fbc4n%40googlegroups.com
> <https://groups.google.com/d/msgid/desktop-pick-and-place/bf154ba4-6f21-4cfc-937f-37bff819fbc4n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Jan]

Hi Micael!
I missed to respond to your encoder part: reading the encoder is a bit
of work configuring the timers. With a little help from CubeMX this
should be not to difficult. Afterwords there are true position values
available without additional cpu overhead. The only question is,
how/where to plug them into smoothieware? One idea I had would be to
calculate each new move with respect to the measured position. Is likely
easy to implement but would only correct position errors on new moves on
that axis. One could also use the idle loop to schedule a movement in
case of a position error. Might interfere with other moves...

Jan

On 10.02.2022 18:27, vespaman wrote:

>>> <https://groups.google.com/d/msgid/desktop-pick-and-place/058185ae-a8b0-4f15-b3ad-cbd8640f18ecn%40googlegroups.com>
>>> <https://groups.google.com/d/msgid/desktop-pick-and-place/058185ae-a8b0-4f15-b3ad-cbd8640f18ecn%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> <https://groups.google.com/d/msgid/desktop-pick-and-place/058185ae-a8b0-4f15-b3ad-cbd8640f18ecn%40googlegroups.com?utm_medium=email&utm_source=footer>.
>>>
>>

> --
> You received this message because you are subscribed to the Google
> Groups "Desktop Pick and Place" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to desktop-pick-and-...@googlegroups.com
> <mailto:desktop-pick-and-...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/desktop-pick-and-place/bf154ba4-6f21-4cfc-937f-37bff819fbc4n%40googlegroups.com
> <https://groups.google.com/d/msgid/desktop-pick-and-place/bf154ba4-6f21-4cfc-937f-37bff819fbc4n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[mark maker]

vespaman, seems your post was delayed for a day!

> if I understand correctly, the "Confirmation Flow Control" is hindering performance, right?

Yes. Is must be enabled if the serial connection does not have flow control itself. Enabling it prevents some valuable optimizations.

I don't know if XON/XOFF would be an option for serial flow control (in the absence of true hardware flow control). According to some discussions I read, it depends on the implementation of the USB bridge, and the of the MCU side. Given the STM32 has ample RAM, maybe the buffer sizes could be increased and XON/XOFF watermarks set generously to cover the inherently delayed reaction of software flow control. We've had multiple examples where it did not work reliably, so I'm currently not very hopeful.

_Mark

Am 10.02.2022 um 18:01 schrieb vespaman:

Hi Jan,

thanks for summing up good & (mostly) bad regarding using original board vs smoothie. I'd say the most troublesome with that, is the memory issue, and if PAXIS=7 is not supported, I suppose it is not really an option, if I want it to work properly. (But why 7 axis (X,Y,Z and then two for peelers)?). Are the pumps also 'axis'?

Also I suppose smoothie-ware, at least currently are running open loop? I guess with the original board, there's at least the chance that someone will try to implement closed loop at some time.

Is there a way to properly test the serial communication of the original board ideally before erasing it, and if not, after? I think that a proper communication is really important, otherwise trouble will follow somehow. And if I understand correctly, the "Confirmation Flow Control" is hindering performance, right?

The 422 can only really go up to 480kbps, since the isolation 422 driver IC on the 48VB does not do faster.

I think yes :-) i would like to test your firmware - trying to avoid broken drag pins and pump failures sounds like a good thing.

The whole config thing, with 36 vs 48 vs openpnp2 vs openpnp1(?) vs firmware this and firmware that is really something that should be summarized somewhere, it is really very confusing to understand which versions of everything to use, since it is not (afaict) a linear versioning of e.g. firmware?

Since I don't have a deadline for when I need the machine, I don't mind testing. I anyway have to learn openpnp, so this is a good opportunity.

I need to start to collect things that are compatible. So I suppose the first question is if anyone are using Jan's firmware with a 48VB, and openpnp 2.x? Would you mind sharing?

Thanks,

 Micael

To unsubscribe from this group and stop receiving emails from it, send an email to desktop-pick-and-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/desktop-pick-and-place/fa10edac-3266-4c1d-9400-4bb55730baddn%40googlegroups.com.

[mark maker]

Wouldn't it be better to go down the road of implementing USB serial, instead of bothering with past-century serial tech?

Somehow I remember someone said there is a  (unpopulated?) CAN connector that could be reused to get the USB signals?

_Mark

Am 11.02.2022 um 17:48 schrieb vespaman:

Hi Jan,

Good to hear about you also thinking about the encoder, and closed loop! I will spend some time to familiarize myself with the smoothie code base, although I am a C programmer, and it was many years since I did any ++ work.  I did briefly look at the serial code, to try to understand why there are issues though, and it looks to me like it is interrupt driven without any sort of buffering. So maybe part of the serial issues some are due to occasional overruns? AFAICT this MPU does not have any hardware buffering in the UART block, but are instead relying on DMA if buffering is needed. I think that, while 115kbs ought to be good, if higher speeds are wanted, most certainly a unbuffered interrupt solution might not be the way. I also don't know how much pressure there is on interrupts in smoothie, but maybe it is substantial(?) given the nature of the IO's. If we can get DMA to work, the need for flow control should really go away.

I was surprised to see that the serial level translator maxed out at 115kbps, but that could be fixed in different ways, like you say, should there be a need.

I hope this message makes it to the list without being deleted. It was rather frustrating yesterday, wanting to answer you guys, but not one message going through.

Will try to flash the board during this weekend.

Cheers,

  Micael

To unsubscribe from this group and stop receiving emails from it, send an email to desktop-pick-and-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/desktop-pick-and-place/59dd8552-debd-4247-a18f-520985509f81n%40googlegroups.com.

[vespaman]

First of all, I'm sorry if my posts are spamming this list, I only see my posts as deleted, but apparently they are (sometimes/always?) coming through anyway...

Well, USB could of course be an option, but that is _much_ more complex (code wise) than a serial port and/or RS422. 

RS422 has the advantage of being isolated, which USB is not. But there are of course USB isolators to solve that issue. 422 is a robust protocol that is perfect for these kind of applications. Also, I suppose we risk that the PC side needs drivers to understand what a smoothie charmhigh board is?  I think marrying a USB solution onto embed+smoothie sounds like a rather big task, at least to me. I also don't know how much available space there is around - the part in our machines only has 512kB FLASH it seems.

Also, I think that the fact that people have to start soldering on the board might make some steer away? Maybe not. Anyway USB needs 90 ohm (if I remember correctly) trace impedance, so it is not necesarily going to work (reliably) using the CAN signals available.

You are correct about XON/OFF - when thinking of it, USB-serial converters tend to buffer, like you say. But XON/OFF with large DMA buffering in the F407 should be good. But then, maybe the handshaking isn't needed anyway.

I'll see if I can manage to lift the top of my machine to get a closer look of the mainboard tomorrow.

  - Micael

[black...@blackboxembedded.com]

Quick note about CL/encoding.

My 36 made a ton of noise via the peeler and XY driver board fan. Also the actual motor driving was in my subjective opinion noisy via the OEM driver. I pulled the OEM  drivers out and found the pcbs to be heavily reworked. I dunno if they were modded to fit the machine or repaired, but I didnt like the rework job I saw on them.

Since the OEM mainboard has pretty accessible step/dir breakout, I assume it would be pretty easy to just 'plop in' cheap encoder drivers. Heres what I used, relatively cheap, much quieter, doesnt need a fan, as of yet anyway, and lastly a big plus for me was being able to run the XY up to 50v. Just food for thought...

[Jan]

It was me, who broad this on the table.
Basically its a question how quick the communication can be and has to
be. Just some background: basically each movement requires a separate
command sequence. One sequence is between 5 and 50 (maybe even more)
ASCII characters long and acknowledged. The controller processes and
queues them. Between queued elements the min. required speed is
calculated to run as fast as possible. Smoothieware can generate step
sequences that operate all requested axes in parallel respecting their
acceleration and feed rate limits forming a straight path. If one wont's
more advanced movement features like jerk limited motion or curved path,
they has to be generated using multiple small straight pieces.
Having hardware flow control provides a way to fill the segment queue
as quickly as possible so that interpolations will be executed as
planed. (if there are no further elements in the queue, smoothieware
plans the last element to finish at speed 0.)
However, Mark has simulated, that full jerk limited curved movements
for pick and place operation provides a roughly 20% gain in speed. Maybe
it can be a little bit more if camera settling times are adjusted. On
the other hand, I've seen a few situation where OpenPnp is missing
optimizations. Fixing them will also provide some gain. (If your goal is
maximum speed, I'd recommend, stick with the Chinese software. They did
a very good job. If the ability to fix flows of the Chinese software is
more important, I'd recommend to switch to OpenPnp.)
I think it should be relatively easy to add hardware flow control back
to the PC. (To my understanding, the data volume send back to the PC is
low, so that the signal from PC to controller can be ignored.) It is
also quite easy to remove the level shifter to get to a higher serial
speed. (The optos allow IIRC 1mbit.) One can further reduce the amount
of data send to the controller by lowering the precision. Implementing a
USB device with USB-serial support is probably more work as it has to
coexist with smoothies other interrupts. The code is available via
CubeMX, it's just the integration, that would have to be done.
Alternatively is should be possible to port reprap which has usb serial
support already build in and is a modern design. According to what I've
read so far, it works quite well with OpenPnp and the maintainers are
open for pnp specific improvements. The only drawback I have found so
far is, that the entire configuration would have to be send to the board
each time as the CHM control board has no sd card...
Concerning the encoders: getting the values is straight forward but due
to the fully planed motion nature of smoothieware, I don't see space to
react on real time position updates quickly yet. Only if he machine is
at still stand, one could compare set and actual position and easily
make corrections.

Jan

>> <https://groups.google.com/d/msgid/desktop-pick-and-place/59dd8552-debd-4247-a18f-520985509f81n%40googlegroups.com?utm_medium=email&utm_source=footer>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "Desktop Pick and Place" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to desktop-pick-and-...@googlegroups.com
> <mailto:desktop-pick-and-...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/desktop-pick-and-place/d5000e75-2d34-2d60-ced9-7c7e6e6a422e%40makr.zone
> <https://groups.google.com/d/msgid/desktop-pick-and-place/d5000e75-2d34-2d60-ced9-7c7e6e6a422e%40makr.zone?utm_medium=email&utm_source=footer>.

[Jan]

This is my second try to send this message...

>> <https://groups.google.com/d/msgid/desktop-pick-and-place/59dd8552-debd-4247-a18f-520985509f81n%40googlegroups.com?utm_medium=email&utm_source=footer>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "Desktop Pick and Place" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to desktop-pick-and-...@googlegroups.com
> <mailto:desktop-pick-and-...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/desktop-pick-and-place/d5000e75-2d34-2d60-ced9-7c7e6e6a422e%40makr.zone
> <https://groups.google.com/d/msgid/desktop-pick-and-place/d5000e75-2d34-2d60-ced9-7c7e6e6a422e%40makr.zone?utm_medium=email&utm_source=footer>.

[black...@blackboxembedded.com]

According to what I've
read so far, it works quite well with OpenPnp and the maintainers are
open for pnp specific improvements. The only drawback I have found so
far is, that the entire configuration would have to be send to the board
each time as the CHM control board has no sd card...

So far its working very well for me. Im running the Full3rdOrder motion function and its very smooth.

The SD Card config/start is actually pretty sweet. So quick and easy to mod the board config on the fly while configuring Openpnp. Makes scratch configuring the machine.xml much easier. Maybe implement SD to serial on the debug port?

[vespaman]

Jan,

Well, I am almost 100% sure that openpnp is the way forward, open source normally is. Also the activity in this forum is encouraging  (even though google takes some of the fun away with its stupid spam handling) :). 

Speed is a good thing, but reliability has to come first. Most of my designs will probably not be very compatible with the 48VB, but hopefully it some of them will be ok, especially with openpnp.

Anyway, I have spent some time to locate a new MCU, so I can desolder the existing, should I want to go back some time in the future. Only thing I found was a 405, but it only lacks Camera block and Ethernet, so it should be OK. 

I have decided to add RTS/CTS and swap the very slow RS232 level converter for a more modern one, and seeing that also the RS232 is already isolated on these machines, and I intend to have the computer inside the 48VB, I might as well just use the RS232. However, I will use the second port, since I find it easier to get the RTS/CTS signals for it, and it also means that the RS422 interface can be left intact as is. (On the 48VB I also have to add another ADUM1201, since it is not populated). Pins for RTS/CTS are unused, so it is a simple thing to add.

With that setup, I the machine should be fine up to 1 Mbit, maybe it will give some speed as is, perhaps especially, as _Mark explained, with the hw handshake, but I I also suspect that adding DMA to the serial driver might help some. But that can be a later step.

USB is something that I might be OK to add, but I do see this as an up hill, thing, and I am (so far) not convinced about its benefits over the relatevely simple enhancement of the serial port. 

Encoders and closed loop is something that interests me more, but I will first get the machine up again, before starting to understand all the ins and outs of that. I suppose checking once the cycle has finished is better than nothing, but like you say, ideally it should be done during the actual stepping.

Cheers,

  Micael

[Jan]

Hi Micael!

On 16.02.2022 19:49, vespaman wrote:
> Jan,
> Well, I am almost 100% sure that openpnp is the way forward, open source
> normally is. Also the activity in this forum is encouraging  (even
> though google takes some of the fun away with its stupid spam handling) :).
>

I agree. At least you can do something if you don't like the behavior.

> Speed is a good thing, but reliability has to come first. Most of my
> designs will probably not be very compatible with the 48VB, but
> hopefully it some of them will be ok, especially with openpnp.

> Agreed. Speed is nice, but only if the machine works reliably.

> Anyway, I have spent some time to locate a new MCU, so I can desolder
> the existing, should I want to go back some time in the future. Only
> thing I found was a 405, but it only lacks Camera block and Ethernet, so
> it should be OK.
> I have decided to add RTS/CTS and swap the very slow RS232 level
> converter for a more modern one, and seeing that also the RS232 is
> already isolated on these machines, and I intend to have the computer
> inside the 48VB, I might as well just use the RS232. However, I will use
> the second port, since I find it easier to get the RTS/CTS signals for
> it, and it also means that the RS422 interface can be left intact as is.
> (On the 48VB I also have to add another ADUM1201, since it is not
> populated). Pins for RTS/CTS are unused, so it is a simple thing to add.
>

I'm with you. Please report your progress.

> With that setup, I the machine should be fine up to 1 Mbit, maybe it
> will give some speed as is, perhaps especially, as _Mark explained, with
> the hw handshake, but I I also suspect that adding DMA to the serial
> driver might help some. But that can be a later step.
>
> USB is something that I might be OK to add, but I do see this as an up
> hill, thing, and I am (so far) not convinced about its benefits over the
> relatevely simple enhancement of the serial port.
>

It depends what features you'd like to have.
ModeratedConstantAcceleration works well without any modification.
Full3dOrderControl will certainly require much more speed. However, I
know (as Wayne reported) that it works with USB and reprap (Duet) but I
don't know how much speed is actually needed. USB provides about 10mbit
which is still 10x more then your suggested modification for 1mbit.
Please keep in mind, that a) commands have to arrive quickly enough at
the controller for segment planing to work well and b) the controller
has to quickly enough do all the planing.
Please also keep in mind, that all the com speed is only needed to
compensate, that the controllers can not generate "perfect" motion
sequences: smoothieware lacks jerk limited motion and does not provide
mode CANON_CONTINUOUS which would allow to drive arcs that deviate from
the exact path by a certain amount.
I see two alternatives: 1) port reprap to the controller board. That
would provide usb support and is know to work well. 2) add some/all of
the missing features like jerk limited motion. Then the com speed is not
so important anymore.

> Encoders and closed loop is something that interests me more, but I will
> first get the machine up again, before starting to understand all the
> ins and outs of that. I suppose checking once the cycle has finished is
> better than nothing, but like you say, ideally it should be done during
> the actual stepping.
>

If you have a good idea how to do that, please let me know. Due to the
all-motion-is-planed-when-the-command-arrives nature its difficult to
react to the encoder value. Its just not foreseen, that an active
sequence can generate more/less steps on any axes. One would have to
modify the timings, that are used for the step generation, on the fly
and still respect all feed rate and acceleration limits - at least to a
certain extent.

Jan

> <https://groups.google.com/d/msgid/desktop-pick-and-place/59dd8552-debd-4247-a18f-520985509f81n%40googlegroups.com?utm_medium=email&utm_source=footer

> <https://groups.google.com/d/msgid/desktop-pick-and-place/59dd8552-debd-4247-a18f-520985509f81n%40googlegroups.com?utm_medium=email&utm_source=footer>>.
>
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Desktop Pick and Place" group.
> > To unsubscribe from this group and stop receiving emails from it,
> send
> > an email to desktop-pick-and-...@googlegroups.com
> > <mailto:desktop-pick-and-...@googlegroups.com>.
> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/desktop-pick-and-place/d5000e75-2d34-2d60-ced9-7c7e6e6a422e%40makr.zone
> <https://groups.google.com/d/msgid/desktop-pick-and-place/d5000e75-2d34-2d60-ced9-7c7e6e6a422e%40makr.zone>
>
> >

> <https://groups.google.com/d/msgid/desktop-pick-and-place/d5000e75-2d34-2d60-ced9-7c7e6e6a422e%40makr.zone?utm_medium=email&utm_source=footer
> <https://groups.google.com/d/msgid/desktop-pick-and-place/d5000e75-2d34-2d60-ced9-7c7e6e6a422e%40makr.zone?utm_medium=email&utm_source=footer>>.

>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Desktop Pick and Place" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to desktop-pick-and-...@googlegroups.com
> <mailto:desktop-pick-and-...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/desktop-pick-and-place/06271541-4e04-45de-8815-ef8d5971e319n%40googlegroups.com
> <https://groups.google.com/d/msgid/desktop-pick-and-place/06271541-4e04-45de-8815-ef8d5971e319n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[vespaman]

Hi all,

So, I swapped the MCU for a stm32f407zgt part (1M flash instead of 512), that I pulled from a devkit, and added the missing isolators for rs232 (remember, I have the 48VB with 422 populated). I also swapped the rs232 level shifter into one capable of 1MBS.  I added HW handshaking signals (in the end I simply used the RS485 pads that can also be used for FS USB later on).

After flashing the board comes up, but it goes into halt immediately (I assume - the LED is rapidly flashing). The debug console does not tell me why, it simply prints out:

Smoothie Running @168MHz

Build version: chmt-af7b8793, Build date: Jan 31 2022 11:32:15, MCU: STM32F4, System Clock: 168MHz
7 axis

NETWORK is disabled

NOTE: One extruder configured and enabled

NOTE: 1 extruders enabled out of 1

Watchdog enabled for 10.000000 seconds

Is there a way to find out why I end up in halt, or did I miss anything (very likely! :) )

Cheers,

 Micael

[vespaman]

So:- It seems that I can communicate with it from openpnp, at least it reports fw version etc. So maybe the rapid flashing is normal at this point in time?

I'll try to go through the full setup of openpnp, to see how far I get...

[Jan]

Mi Micael!
Nice work! Rapidly flashing led is fine and the output looks as if
you're using my firmware. The led is operated int he main/idle loop and
hence signals when the board is idle. Use a terminal or pronterface to
connect and check if you can talk to the board.
Did you checked the electrical connections between U28, U29 and U30.
IIRC RS232 and RS485 share the same Uart/ios, hence there might be
multiple drivers on the RX side now.
Concerning hardware handshake: I've studdied the RM and the hardware
generated signals seems not to do what we wont. The Read-To-Receive
signal is deasserted when the shift register is full. In order to
facilitate that, one would have to disable the interupt at some point
and later reeanble it. I've also read, that deasserting Read-To-Receive
is not guaranteed to stop transmission immediately. Depending on the
sender hardware, there might be data in a fifo which will be send out
anyhow. My proposal is to use the Read-To-Receive signal as GPIO and
operate it based on the ring buffer level, thats filled by the receive
interrupt and drained in user space.

Jan

On 25.02.2022 11:50, vespaman wrote:
> Hi all,
> So, I swapped the MCU for a stm32f407zgt part (1M flash instead of 512),
> that I pulled from a devkit, and added the missing isolators for rs232
> (remember, I have the 48VB with 422 populated). I also swapped the rs232
> level shifter into one capable of 1MBS.  I added HW handshaking signals
> (in the end I simply used the RS485 pads that can also be used for FS
> USB later on).
> After flashing the board comes up, but it goes into halt immediately (I
> assume - the LED is rapidly flashing). The debug console does not tell
> me why, it simply prints out:
> Smoothie Running @168MHz
> Build version: chmt-af7b8793, Build date: Jan 31 2022 11:32:15, MCU:
> STM32F4, System Clock: 168MHz
> 7 axis
> NETWORK is disabled
> NOTE: One extruder configured and enabled
> NOTE: 1 extruders enabled out of 1
> Watchdog enabled for 10.000000 seconds
>
>
>
>

> <https://groups.google.com/d/msgid/desktop-pick-and-place/06271541-4e04-45de-8815-ef8d5971e319n%40googlegroups.com?utm_medium=email&utm_source=footer
> <https://groups.google.com/d/msgid/desktop-pick-and-place/06271541-4e04-45de-8815-ef8d5971e319n%40googlegroups.com?utm_medium=email&utm_source=footer>>.

>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Desktop Pick and Place" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to desktop-pick-and-...@googlegroups.com
> <mailto:desktop-pick-and-...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/desktop-pick-and-place/f5ac8177-7a42-4a6e-b28e-1dad42e1ac46n%40googlegroups.com
> <https://groups.google.com/d/msgid/desktop-pick-and-place/f5ac8177-7a42-4a6e-b28e-1dad42e1ac46n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[vespaman]

Thanks, Jan!

Yes, this is your firmware, I have not yet tried to build the fw myself, since, after all, I am a newbie with both CharmHigh and OpenPnP :)

But I will have to tackle that once I have gotten a bit further..

>>Did you checked the electrical connections between U28, U29 and U30.
>>IIRC RS232 and RS485 share the same Uart/ios, hence there might be
>>multiple drivers on the RX side now.

There's a 0-ohm resistor selection (R131/R132) that defines rx from the 422 receiver or the 232 receiver, which has to be moved on 48vb if 232 is preferred over 422.

Granted, I have limited experience of the STM32 (more of a NXP (the former freescale products) and TI guy), but AFAICT, the HW handshaking is doing exactly what we want (or am I missing something?);

The RXNE is is cleared afaict, when reading the register from the receive data register, so it should work automagically no?

In my book ST are using the wrong nomenclature, to me the above is actually CTS signalling, but looking at their connection diagram, the swap the pins, so I suppose you could argue both ways.

Anyway, I think it should work as it is normally doing in most micros. I can't believe that there are transmitters that are outputting their buffers before reading the state of their CTS, I would consider them being broken in that case. It is after all a character per character handshake.

Having said that, we ought to enable DMA ASAP, since it makes no sense not to (unless I have read the wrong piece of code, it is not enabled). The STM32 seems to have a very easy to use DMA, that should be almost invisible to the smoothie rx driver (using/reacting on the same interrupt). Doing so, I suspect that we will not really need the HW handshaking, at least not at 115200. But @921k we probably will.

 Micael

[mark maker]

Sounds like good progress!

> Doing so, I suspect that we will not really need the HW handshaking, at least not at 115200. But @921k we probably will.

I think you will always need it, unless you have a gigantic serial read buffer. All the Open Source G-code interpreters that I looked at (including Smoothie) have a) only a limited number of move queue buffers, so it is well possible that the queue will fill up and back up the G-code parser, or b) they cannot execute certain G-code commands until all the move queue buffers have been drained, i.e. the queued moves executed physically.

When either one of those conditions happens, the G-code parser will block and no longer read commands from the serial buffer, which obviously can cause flow control to trigger. The most prominent command doing that is M400 which explicitly tells the machine to wait with any response or further G-code processing, until all the queued moves are complete. We need that so we can sync the camera to the machine (and other stuff). Needless to say, it can take a very long time for machine moves to complete (many seconds).

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/desktop-pick-and-place/6d334053-585f-40dc-9c22-9ab9134da7d5n%40googlegroups.com.

[vespaman]

OK, good to know, then there should be no reason not to use it going forward, should one be interested in maximizing throughput.

Do you have any thoughts/suggestion for how big serial buffer we should aim at?

 Micael

[vespaman]

Also, having the 46vb in my office, I realize that I have to fix some intelligent fan control, there are two fans that are not controlled at all, and they sound like the jet engine of a fan I had in my old Amiga 2000. Got to cut those wires to start with...

[mark maker]

> Do you have any thoughts/suggestion for how big serial buffer we should aim at?

Not sure.

As I understand it, RTS/CTS are truly bit-synchronous (unlike XON/XOFF), so there is no need for extensive buffering to cover any delays. As long as you can store the longest G-code commands, I guess you're OK. Maybe not even that is needed, because the G-code parser provides a large enough string buffer.

I also guess that one or more packet(s) will be buffered in the USB stack.

And more buffering could happen on the device driver level, on the PC side.

I don't know how these levels work together. I guess it would be good to cover the delay until a backed up sender process (like OpenPnP) can be woken up again. But where, I have no clue.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/desktop-pick-and-place/d5468efa-f136-4cd4-b9dc-033239f4d9fbn%40googlegroups.com.

[vespaman]

I have added hw handshake to the code now, but have to test more, and also the startup of smoothie is not good, since it hangs waiting for PC before setting up its peripherals properly, because the pumps start at full power etc. In fact this is a bit annoying to me, even if starting without HW flow control - the pumps are coughing on power on. So I'd like to see if I can find a nicer startup.

If not, I have to find a way to at least not hang so early in the startup, who knows, maybe things can burn up (the feeder solenoid comes to mind).

But at least there are some progress, will continue tomorrow.

 Micael

[Jan]

Hi Micael!
I'd say that DMA will be of little help only because GCode is ASCII and
expected to be interpreted at line end. So there is no way to configure
"read that many bytes and then give me an interrupt". One would need a
"trigger word" that could be setup to line end and trigger an interrupt
if received. To my knowledge that's not supported.
Concerning the hardware generated flow control signal: it seems, that
ST took the easy route and reused the receive buffer full status flag
which is also used as receive interrupt. If the transmitter strictly
follows the signal, one would delay the communication by the interrupt
latency. I think it would be better to deassert the signal if the
receive buffer (256 bytes on the smoothie code I've checked) is almost
full and deassert it when more space becomes available. The F4 also has
a lot of memory currently unused. It would be easy to enlarge the
receive buffer. In addition I've found on Wikipedia
(https://en.wikipedia.org/wiki/RS-232#RTS,_CTS,_and_RTR): "Equipment
using this protocol must be prepared to buffer some extra data, since
the remote system may have begun transmitting just before the local
system de-asserts RTR."
Unfortunately all this work only makes sense if the improvement will be
significant and sufficient to switch from ModeratedConstantAcceleration
to Simulated3rdOrderControl motion, which I'm currently unable to
evaluate because I don't know how.
Remember, that even with Confirmation Flow Control the machine works
very well with ModeratedConstantAcceleration.

Jan

On 25.02.2022 17:02, vespaman wrote:
> Thanks, Jan!
> Yes, this is your firmware, I have not yet tried to build the fw myself,
> since, after all, I am a newbie with both CharmHigh and OpenPnP :)
> But I will have to tackle that once I have gotten a bit further..
>
> >>Did you checked the electrical connections between U28, U29 and U30.
> >>IIRC RS232 and RS485 share the same Uart/ios, hence there might be
> >>multiple drivers on the RX side now.
>
> There's a 0-ohm resistor selection (R131/R132) that defines rx from the
> 422 receiver or the 232 receiver, which has to be moved on 48vb if 232
> is preferred over 422.
>
> Granted, I have limited experience of the STM32 (more of a NXP (the
> former freescale products) and TI guy), but AFAICT, the HW handshaking
> is doing exactly what we want (or am I missing something?);
>

> <https://groups.google.com/d/msgid/desktop-pick-and-place/f5ac8177-7a42-4a6e-b28e-1dad42e1ac46n%40googlegroups.com?utm_medium=email&utm_source=footer
> <https://groups.google.com/d/msgid/desktop-pick-and-place/f5ac8177-7a42-4a6e-b28e-1dad42e1ac46n%40googlegroups.com?utm_medium=email&utm_source=footer>>.

>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Desktop Pick and Place" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to desktop-pick-and-...@googlegroups.com
> <mailto:desktop-pick-and-...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/desktop-pick-and-place/6d334053-585f-40dc-9c22-9ab9134da7d5n%40googlegroups.com
> <https://groups.google.com/d/msgid/desktop-pick-and-place/6d334053-585f-40dc-9c22-9ab9134da7d5n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[vespaman]

Hi Jan,

I'm sure this message will be deleted as well (google groups really must hate me!), if it does, I will try to create a new account..

I finished the hw handshake in the week-end, and I also set the speed to 921,6kbits/s and it seems to work well.

When running at this higher speed, like you say, the interrupt latency in the code will make the hw handshake to stop the incoming data, until CPU has emptied the receive register (therefore slowing down the effective speed). If we enable DMA, the receive register will be emptied by the DMA engine as soon as data arrive, therefore incoming data can continue without any latency from CPU. This way we will achieve the line speed. So yes, I am certain that DMA helps, and I'd say it is mandatory. The maximum we can hope to get is 3Mbit over this interface, but I think 921.6 is a good start (and it seems to work fine so far) because most RS232 interfaces does this effortlessly. I suspect this simple DMA setup is why ST did not put in any buffers in the serial blocks - the DMA would anyway always be better.

This is a simple fix, but like all simple fixes, it also has a downside, in that the CPU will still be hit by an interrupt each arriving byte. This will decrease the overall available performance for the CPU.

If we find out (or maybe you guys already knows?), that this CPU interrupts will hurt too much, we can move to more advanced management of the DMA, like disabling the receive char interrupt if the G code job queue is already full/at high mark, and re-enable at a low water mark. Opportunistic data polling may take place in between. Or perhaps disabling the receive byte interrupt altogether and only use polling from the DMA buffer. Given there's already off chip data buffers (in the USB interface for example), and this seems to work, having a local buffer that is managed totally by the DMA engine will give better overall performance, even if polling, since the CPU can then do whatever is most important at any given time. Remember that the DMA will control the RTS signal, so having a local buffer of a couple of hundred bytes (?) for the CPU pick data from asap, can really only be good. Right?

This will possibly be a little bit bigger change in the code, and maybe there are other bottlenecks that are better focused on. Anyway I think small steps are good, not to break anything.

OK, google delete this message as you always are!

Cheers

  Micael

[Hank Kauffmann]

Jan,  Micael

I'm trying to stay away from jumping into coding, but I hope you don't mind me lobbing some ideas at you.

Some of the newer processors will recognize a specific character (say a '\n') in a stream and interrupt, and/or when there is no communication for 3 symbol periods. The older ones don't, however, they will wake on either a break or idle character. Sending a break character could adversely affect the communications, but the idle character could be interesting if it can be generated on Windows and survive transport through the USB layers ...

https://stm32f4-discovery.net/2017/07/stm32-tutorial-efficiently-receive-uart-data-using-dma/

Alternatively you can add a timer to wake periodically. I would also add detection of buffer 1/2 full so that the interrupt wakes and processes input before the buffer is completely filled.

Alternatively, alternatively, if the processor is relatively not busy, just bite the bullet and use a character by character interrupt at the highest priority. The trick is to only copy the byte to the receiving butter and to watch for your termination character(s) or condition. When the terminating condition is met, then trigger a software interrupt to process the command string that was stored in the buffer. This interrupt would be set up to run at a lower priority than the UART, PWM or motor centric routines . You will likely have to double buffer the reception buffer or set up a simple ring buffer to hold the commands in waiting. Also for the fastest code with the least overhead in the high priority interrupt, avoid using library functions and just grab the data out of the hardware registers

DMA for output characters ... Always, just make sure you have a way to handle overlapping outputs. I use circular output buffers.

- Hank

To view this discussion on the web visit https://groups.google.com/d/msgid/desktop-pick-and-place/40f85bb1-ea8f-2629-ad88-5874c61dc7d2%40googlemail.com.

[vespaman]

Hi Hank,

Not at all! There's always interesting to discuss and learn about different views.

The way I had intended to solve this particular problem was by removing the current circular buffer and replacing it with two ping-pong buffers, filled by DMA automatically. But this was before I got to know about the circular DMA in the STM32. Thanks for the link!

If possible, I can try using that instead, but I have to find out if the DMA can stop when reaching his tail in that case. (since the HW flow control are actually pacing the PC client, this is important).

I think, we (or at least I) don't exactly know how busy the CPU is, so we have to assume. My fear is that there are very hard real-time demands here or there in the code (since there's so much I/O). So I think a hi prio interrupt solution is not really a way I would like to pursue. Then I would probably prefer to leave it as is. Also, I have no experience of embed, so that is a new can of worms for me. ( FreeRTOS is my normal corner)

For output, I think we can just leave it as is, since it is so little data sent back. (Just my ignorant guess!)

Hopefully I can find some time to dig into this during the week-end.  Loads of work right now, but it is quite nice to have something on the side, for the brain to relax with... :)

By the way is it only ascii or are there also binary blobs being sent on this interface?

Cheers,

 Micael

[vespaman]

Hi Wayne,

So I'm now (almost exactly one year later!) contemplating substituting my XY (+peeler) driver board with (probably) the same drivers (T60) you selected (Just planning phase right now, don't have time to rip the machine apart until next month). But did you go T60 also for the peelers, or did you choose something else for them? Or did you full throttle, also substituting the nozzle drivers as well? (That would be a lot of drivers, will they fit?). If not, did you keep the 36V?

Also, if you have any kind of pictures of how you organized the guts with the new drivers and power supply, I'd be very interested :-)

 - Micael

[Wayne Black]

Hey Micael,

The 48V has just sat in the crate it is shipped in. I purely use the 36V for one off prototyping builds and dont use it all for production. There's a company in San Jose, Rush PCB that we use for production boards. Anyrate, for the way I'm using the 36 I have mapped the left hand feeders as trays and expose the # components needed by peeling back the tape manually. This approach was due to a drag pin crash and I have since yet to fix the issue other than just removing it from the head.  

I have done nothing w the bigger aliexpress head I bought. No time to work on it...

For mounting the Duet controller board and offboard drivers within the 36 I got really lazy. I found a plastic cutting board that fit the internal footprint of the machine and mounted all the compents on that, then slipped the whole thing into the 36. I works fairly well as I didnt have to modify the 36 enclosure at all. The cutting board is 0.5" thick and I thought I may have a height clearance issue w the motor drivers. It all 'just' fits. I actaully have to build a prototype this coming week. ill try and get some photos. It ain't pretty though ;)

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

To view this discussion on the web visit https://groups.google.com/d/msgid/desktop-pick-and-place/39634b31-3fc1-4b5d-bf73-5b1ed936a5c4n%40googlegroups.com.

--

Wayne Black

Owner

Black Box Embedded, LLC

black...@blackboxembedded.com

1.831.682.4964

[vespaman]

Well, I am also way behind my original plan on my machine/setup. I have so far used a large EMS that runs the production boards, also for prototypes. Only this past week, I have started to move two new jobs to the machine, and will dedicate upcoming weeks to get them through, no matter what. :-)

I realized only yesterday, that I completely forgot about the right hand peeler control, just as I had disconnected the jlink from the main board for the first time since I got the machine.

OK, so you are only using the T60's for the X&Y? And use the Duet internal for the rest? So that means, that you have both original 36Volt supply as well as an added 48Volt?

I need to get rid of the larger 4 driver board in order to fit anything properly, so I cannot keep the peelers on that board.

Right now, I am thinking that I will keep the smaller driver (with only the three nozzle drivers), and maybe see if the three driver board will work with the peelers, and get the fancier drivers for the nozzles.

The cost goes up drastically if I would substitute all 7 axes with external drivers from a company such as rtelligent. In that case it might be a better route to go Duet like you have. But it would be nice to get rid of the 36Volt supply.

And I kind of like the original chmt main board now, after having done some work on it. :-)

I think Rtelligent has some drivers that can do three steppers, that would at least take care of the space issue. Another solution might be to mount them standing up in a row. But maybe they need the larger area to be screwed down to chassis as a means to get rid of heat, or are they ok without?

There's a model T60Plus as well, that has USB built in, and is more flexible, at the cost of micro stepping resolution. Have you considered that one? 

Sorry for all the questions, hope you don't mind. And if you get the chance to take some pictures; don't worry, I know how a test bed can look like :-)

 - Micael

[Wayne Black]

Yes T60 @48V via CAN breakout from Duet Mini 5. This is so much quieter and faster than the oem setup. You only hear the mechanics when machine rapids. IIRC the Duet Mini5 is limited to 24V so I had to go to CAN expansion for the XY drivers and bumped that to 48V for speed.

Heres a pic of what Im doing;

To view this discussion on the web visit https://groups.google.com/d/msgid/desktop-pick-and-place/5cb54ee7-0430-4fd8-9966-2001ca52dda0n%40googlegroups.com.

[Wayne Black]

lol actually looking at the pic its the Duet HC6 I have in there. I have 5 diff machines (differing processes) that all use Duet HC6 or the Mini5. Duet is so easy to connect and config with super active support/forum. They are a great way to go for control, but the price is premium relative to other 6 axis control boards.

[vespaman]

That doesn't look bad at all! Inevitable, there will be a lot of cables, so, hard to have super clean esp on a retrofit.

Having the drivers standing like that probably makes it possible to fit in a 48. Hopefully. I will have to do some serious measuring of the 48 internals. If the 36Volt power goes out, it will def work, but keeping all four power supplies means bigger rearrangements. The pumps are in the back on the 48, so at least they are not part of the problem. (well, they are noisy, so part of another problem).

I think keeping the chmt main board, adding a 48V supply, 2x T60 and 3x R60x2 will probably be on par with a duet HC6, or thereabouts.  In fact maybe it is about the same price to go 7xT60. But then there's the space issue. (But then again, no 36V power). Got to measure.

Why exactly do you need the CAN boards on a 36? Can you not pull out the step/dir on any other available pins?

[Wayne Black]

IIRC HC6 has no step/dir io and the mini5 has x2 step/dir io. The preferred break out for Duet is CANFD. IIRC I used the HC as I drive the nema 23 peeler off the on board driver of the 6HC. The HC has high current 5A drivers. I think the mini5 is limited to 2A. The Z and C are fine on the Mini5 but I think I concluded the Peeler motor was abit much of its onboard driver so I used the 6HC. Hence the need for the CAN. Works very well. The Mini5 also has CAN FD...

To view this discussion on the web visit https://groups.google.com/d/msgid/desktop-pick-and-place/46a0f9e9-5750-4039-8967-b7847f958675n%40googlegroups.com.

[vespaman]

I see! There's always something. :-)

I have now measured, and think even the R60x3 will fit standing up, if screwed to the bottom of the 48VB. This might be the best option for me, since this means 2x T60, 2x R60x3.

One of the benefits with using a fancy external driver is the possibility to trim down the current on idle motors (esp the nozzle motors that get uncomfortably hot). Maybe this can also be trimmed with the Duets, but the OEM has only on/off.

So currently, my thoughts are to stay with the OEM mainboard for now, but change all drivers and change the 36V power supply for a 48V one. The only downside that I can see with this really, is missing the better motion control in fw. But that might be possible to solve going forward. And there's also the possibility to go for a Duet 6XD or something else in the future as well.

But there's still time to iterate my thoughts, which I'm sure I will :-)

 - Micael

[Jan]

Hi Micael!

On 19.02.2023 10:26, vespaman wrote:
[...]

> And I kind of like the original chmt main board now, after having done
> some work on it. :-)

RepRap is actively ported to STM32F4: https://teamgloomy.github.io/ So
you have the addition option to keep the original board and run it with
Duet firmware.
I think that porting should not be that difficult: there is no special
hardware around, just the MCU, a replacement the sdcard/configuration
file is needed, six axes support is already available (X, Y, Z, Z1, Z2,
peeler), the second peeler of the 48VB could be operated in parallel
with the first if RepRap does not support seven axes. I did not checked
if RepRap supports serial ports for communication.

Jan

[...]

> <https://www.amazon.com/RTELLIGENT-Stepper-24-50VDC-Control-Stepping/dp/B07Z77GYZB/ref=sr_1_5?crid=1NOO6FKB7NCDN&keywords=t60+stepper+driver&qid=1644599266&sprefix=t60+driver%2Caps%2C196&sr=8-5>, relatively cheap, much quieter, doesnt need a fan, as of yet anyway, and lastly a big plus for me was being able to run the XY up to 50v. Just food for thought...

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

> https://groups.google.com/d/msgid/desktop-pick-and-place/39634b31-3fc1-4b5d-bf73-5b1ed936a5c4n%40googlegroups.com <https://groups.google.com/d/msgid/desktop-pick-and-place/39634b31-3fc1-4b5d-bf73-5b1ed936a5c4n%40googlegroups.com?utm_medium=email&utm_source=footer>.

>
>
>
> --
> Wayne Black
> Owner
> Black Box Embedded, LLC
> black...@blackboxembedded.com

> 1.831.682.4964 <tel:(831)%20682-4964>

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

> <mailto:desktop-pick-and-...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/desktop-pick-and-place/5cb54ee7-0430-4fd8-9966-2001ca52dda0n%40googlegroups.com <https://groups.google.com/d/msgid/desktop-pick-and-place/5cb54ee7-0430-4fd8-9966-2001ca52dda0n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[vespaman]

Hi Jan!

Yes, this has crossed my mind. And since the board is rather well documented, fits the chmt naturally (of course), this is definitely an option. IIRC, RepRap is also based on FreeRTOS, which I have worked a lot with. Unfortunately for me, I think it is still C++, which I am struggling a bit with (I want clean C :-) ), but that shouldn't really be too much of a problem. Did not know it lacks support for 7 axes though. That is a bit disappointing. But maybe something that can be added.

Let's see how things turns out. Smoothie isn't too bad, and I still have to play properly with the simulated 3rd order... (when/if I ever learns all the lingo).

Regards,

 Micael

[Jan]

Hi Micael!
Don't get me wrong, I don't know how many axes RepRap on STM32F4
supports. I only wonted to mention that in case it only supports 6, one
could still drive left and right peeler of a 48VB as one axis.

Jan

> <https://www.amazon.com/RTELLIGENT-Stepper-24-50VDC-Control-Stepping/dp/B07Z77GYZB/ref=sr_1_5?crid=1NOO6FKB7NCDN&keywords=t60+stepper+driver&qid=1644599266&sprefix=t60+driver%2Caps%2C196&sr=8-5 <https://www.amazon.com/RTELLIGENT-Stepper-24-50VDC-Control-Stepping/dp/B07Z77GYZB/ref=sr_1_5?crid=1NOO6FKB7NCDN&keywords=t60+stepper+driver&qid=1644599266&sprefix=t60+driver%2Caps%2C196&sr=8-5>>, relatively cheap, much quieter, doesnt need a fan, as of yet anyway, and lastly a big plus for me was being able to run the XY up to 50v. Just food for thought...

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

> https://groups.google.com/d/msgid/desktop-pick-and-place/39634b31-3fc1-4b5d-bf73-5b1ed936a5c4n%40googlegroups.com <https://groups.google.com/d/msgid/desktop-pick-and-place/39634b31-3fc1-4b5d-bf73-5b1ed936a5c4n%40googlegroups.com> <https://groups.google.com/d/msgid/desktop-pick-and-place/39634b31-3fc1-4b5d-bf73-5b1ed936a5c4n%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/desktop-pick-and-place/39634b31-3fc1-4b5d-bf73-5b1ed936a5c4n%40googlegroups.com?utm_medium=email&utm_source=footer>>.

> >
> >
> >
> > --
> > Wayne Black
> > Owner
> > Black Box Embedded, LLC
> > black...@blackboxembedded.com

> > 1.831.682.4964 <tel:(831)%20682-4964> <tel:(831)%20682-4964>

> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Desktop Pick and Place" group.
> > To unsubscribe from this group and stop receiving emails from it,
> send
> > an email to desktop-pick-and-...@googlegroups.com
> > <mailto:desktop-pick-and-...@googlegroups.com>.
> > To view this discussion on the web visit
> >

> https://groups.google.com/d/msgid/desktop-pick-and-place/5cb54ee7-0430-4fd8-9966-2001ca52dda0n%40googlegroups.com <https://groups.google.com/d/msgid/desktop-pick-and-place/5cb54ee7-0430-4fd8-9966-2001ca52dda0n%40googlegroups.com> <https://groups.google.com/d/msgid/desktop-pick-and-place/5cb54ee7-0430-4fd8-9966-2001ca52dda0n%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/desktop-pick-and-place/5cb54ee7-0430-4fd8-9966-2001ca52dda0n%40googlegroups.com?utm_medium=email&utm_source=footer>>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "Desktop Pick and Place" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to desktop-pick-and-...@googlegroups.com
> <mailto:desktop-pick-and-...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/desktop-pick-and-place/b65cf8b6-d681-4b72-bf71-a4e9047d60f3n%40googlegroups.com <https://groups.google.com/d/msgid/desktop-pick-and-place/b65cf8b6-d681-4b72-bf71-a4e9047d60f3n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[vespaman]

Hi Jan,

Aha, that makes sense. In fact it sounded strange with the limit of 6 :)

I think, probably it is not a huge task to try RepRap on the chmt mainbard, like you say. And doing the serial interface (if it is missing) would be easy for me now. Also using USB would be easy if the code is already there. But there's always some things (e.g. vacuum sensors etc) that most likely will take some time.

Thanks for clarifying,

 Micael

[John]

I picked up a CHMT36 a few weeks back from one of the folks in this forum I've installed the latest version of the software from the Charmhigh depository on the Spark fun site and am working my way through the process. I've managed to import a few of my own board layouts without much effort and am able to pick parts an place them in the general vicinity of their respective pads. The logic of the software is a bit confusing, so I sense it might be a lot of work to use it on an ongoing basis. The object visual parameter process is very confusing and doesn't seem to match the on-line vidoes from Charmhigh

Prior to getting the Charmhigh, I picked up a Duet 6HC and was considering going down the path of a DIY build. The fact that you've gone down the Duet conversion is very interesting to me. Are you saying the Charmhigh motors are a high voltage than what the Duet, which I thought is 48 volts, not 36V. The Duet is open loop so went with drivers with encoder feedback. Did you go with the 6XD, since you aren't using the stepper drives?

Thanks,

John

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

To view this discussion on the web visit https://groups.google.com/d/msgid/desktop-pick-and-place/058185ae-a8b0-4f15-b3ad-cbd8640f18ecn%40googlegroups.com <https://groups.google.com/d/msgid/desktop-pick-and-place/058185ae-a8b0-4f15-b3ad-cbd8640f18ecn%40googlegroups.com?utm_medium=email&utm_source=footer>.