New version of my controller for OpenPnp - comments welcomed

[Jarosław Karwik]

Hi,

I am about to order boards for new version of my controller for OpenPnp.

Some time ago I have shown first version, after some experimenting new version is about to be born.

Few features:

- Based on 480MHz Cortex M7 - STM32H743VI

- Both USB and ethernet connection ( ethernet to be used for control, usb for firmware upgrade )

- Supports 2 axis with encoders and differential step/dir , can be also used as TTL outputs

- Supports one axis with TTL outputs

- Expansion slot with capabilty to support more axes ( SPI/I2C/Timers etc.)

- Designed to operate with more boards over FD CAN  ( master unit  connected to ethernet with at least one more slave unit taking commands over 2Mbit FD CAN )

I have designed very simplistic shield to operate my Peter's head  (3x stick drivers + 2x vaccum sensors) 

I plan full 3rd order motion support ( speed/acceleration/jerk)

The design files are here:

https://github.com/jarekkt/UniController

( note - software is still in transition process from previous version)

[Marek T.]

To be sure...

The "very simplistic shield" is the slave board connected to the master over the FD CAN, right?

And it can be multiplied if we need to handle more than one Peter's head?

So to connect 3 slaves we need the power line and single CAN mag?

And the vacuums are read over this CAN either?

4 times "yes"?

[Jarosław Karwik]

4x yes.

You connect first master board with ethernet cable. It should handle X/Y axis and synchronization of all other commands sent to slaves. It does have several I/O to handle end switches, relays, valves etc. Designed for external controllers using step/dire over differential lines ( well, TTL signals can be found on shield connector). With capability to connect differential encoders.

Second module - as slave - will handle Peters head. The shield I made is just a socket board for three stick controllers and two vacuum sensors. Connected directly to slave CPU, can be accessed through master board with few milliseconds of latency.

There should be no problem to use many slaves as it is unlikely you control them at once. And CAN FD with 64 bytes of message frame makes it possible without too big overhead.

The whole system will be seen as single TCP based gcode controller - with full 3rd order motion capability. Or at least with buffer big enough to service simulated 3rd order. 

You could also connect these boards as separate masters using switch, but then synchronizing these boards would be more complicated.

I have put RJ45 connectors for FD CAN  as well, so standard ready made cables will be usable.

 I will actually have one more controller handling conveyor with its sensors ( I have changed AC motor in my machine to stepper)

[Jarosław Karwik]

This would look like this ( main controller with head shield)

[Dave B.]

Have you considered the MPX/MPXH6xxx sensors instead of the MPX4xxx sensors?  The form factor is a lot more compact (SO8).

-Dave

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/1365a84f-86a5-4282-96ae-d69917195b47n%40googlegroups.com.

[Jarosław Karwik]

I need it for my main application, but there is benefit to add it as assembly option :-)

[Jarosław Karwik]

Got the boards and stencils :-)

[Dave B.]

Looking sharp.

-D

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/1164520d-c9b8-4823-bc16-9b52462bfedan%40googlegroups.com.

[Jarosław Karwik]

After assembly, not yet powered. Peter's head as size reference - in my machine one such set it will be assmbled behind it

[Jarosław Karwik]

Few updates :-)

Base system communication is working ( USB and ethernet ).

Took a while as Stm32CubeIDE and its CubeMX plugin does not generate working ethernet application  for H7 processors.

Small latency test with M115  - response time is below 2ms ( most due to lwip limitations of netconn interface - which is not multithreaded)

Now the real testing of pulse calculations and generations will begin :)

I have also checked how much  buffering can be done - with about 60% of RAM in use I am able to buffer  300 gcode commands and 600 seven segment S curve  axis motions ( whichever limit comes first)

[Mike Menci]

Good start - keep us posted of your progress!