Any ESP32 controller FW? (Super simple needs)

[vespaman]

Hi all,

I have one of these side project, to create a nozzle changer for my chmt48, and now I am close enough with the mechanical hardware, that I'd like to test it out.

Therefore, I need a way to connect e.g. a esp32 to OpenPnP.

Now, since this is a very simple application (basically only PWM's and maybe a sensor, no stepper driving or the likes), I kind of hope that there's something like this already out there.

Basically the gcode parser and connection stuff done, the rest I anyway need to do myself.

Does anyone know of a project that would be a good starting point?

I could use the smoothie firmware on the chmt to drive this nozzle changer over rs485 or CAN, but this is might be more work, which is why I thought I should ask before making a decision.

 - Micael

[Mr covert]

I used a ESP for a wireless vacuum sensor.  I used some generic terminal code and set a new code driver via IP  in openpnp. It worked really well for a few years till I retired the machine 2 months ago.  

--
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/f77d9839-4f5f-4304-9001-46c10b56874en%40googlegroups.com.

[Jan]

Hi Micael!

On 29.03.2024 18:55, vespaman wrote:
> Hi all,
>
> I have one of these side project, to create a nozzle changer for my
> chmt48, and now I am close enough with the mechanical hardware, that I'd
> like to test it out.
>

Very cool! Do you have any further information?

> Therefore, I need a way to connect e.g. a esp32 to OpenPnP.
>
> Now, since this is a very simple application (basically only PWM's and
> maybe a sensor, no stepper driving or the likes), I kind of hope that
> there's something like this already out there.
> Basically the gcode parser and connection stuff done, the rest I anyway
> need to do myself.
>

You do not need GCode per-se. As you configure the command to send in
OpenPnP, you can specify anything you like. Also GCode commands itself
could be parsed using a simple strcmp() chain. Arguments might require a
little bit more work. But as you control both sides, its very easy.

> Does anyone know of a project that would be a good starting point?
>
> I could use the smoothie firmware on the chmt to drive this nozzle
> changer over rs485 or CAN, but this is might be more work, which is why
> I thought I should ask before making a decision.
>

It shall be straight forward to add a command to the dispatcher and
forward its argument to the second serial. One or two characters could
be send straight away and for more you already implemented DMA based
transfer...

Jan

[vespaman]

OK, great! So it's just to accept a TCP connection silently?

And then, and parse the data as sent from OpenPnP.

The connection part is what I know the least of, being over IP. But this is also very convenient, esp during testing, not to have to add more hardware.

 - Micael

[vespaman]

Hi Jan,

> I have one of these side project, to create a nozzle changer for my

>

Very cool! Do you have any further information?

Well, for now, I can say that it is a 3d printed solution, with some standard parts, and that it ought to fit also the chmt36, it sits in front of the component tray/discard area, so no radical change is needed on a stock machine. I will settle for 10 nozzle bays, but I think, on the 48VB, it could be max 12-ish bays. Maybe a few less on the 36.

I'll start a new thread about it, once I have done some more verification, there are still some work to be done.

I am a little bit worried about the control from OpenPnP, afaict, there no way to indicate from OpenPnP if it wants to pick up a new nozzle tip, or dispose one. If this is true, this needs to built into my controller, and I have to make sure they both agree on nozzle tip status. Or maybe I misunderstood the changer setup, I haven't looked into that part properly.

OpenPnP, you can specify anything you like. Also GCode commands itself
could be parsed using a simple strcmp() chain. Arguments might require a
little bit more work. But as you control both sides, its very easy.

I think I am unsure about the TCP connection, that is, if OpenPnP wants some startup negotiating, but I'll do some tests, tomorrow.

 

> I could use the smoothie firmware on the chmt to drive this nozzle
> changer over rs485 or CAN, but this is might be more work, which is why
> I thought I should ask before making a decision.
>
It shall be straight forward to add a command to the dispatcher and
forward its argument to the second serial. One or two characters could
be send straight away and for more you already implemented DMA based
transfer...

Yes, this is clear, and quite possibly the end solution, but it means that I have to open the machine up, to solder wires onto the board, which I don't have time to right now, so a "stand-alone" wifi solution is less of a hassle, and I can use my machine in production, while scrubbing issues from the nozzle changer sub system. At least until I have verified that it is worth finishing up this solution.

 

 - Micael

[Jan]

On 30.03.2024 17:09, vespaman wrote:
[...]

> I am a little bit worried about the control from OpenPnP, afaict, there
> no way to indicate from OpenPnP if it wants to pick up a new nozzle tip,
> or dispose one. If this is true, this needs to built into my controller,
> and I have to make sure they both agree on nozzle tip status. Or maybe I
> misunderstood the changer setup, I haven't looked into that part properly.
>

From studying the code I can tell, that each nozzle tip has its own
changer sequence. Each sequence has four way points and can actuate one
actuator between each two. So a total of three actuators can be freely
configured. Actuators are only actuated TRUE/ON. On load, the sequence
is executed in forward direction, on unload backward.

[...]

> I think I am unsure about the TCP connection, that is, if OpenPnP
> wants some startup negotiating, but I'll do some tests, tomorrow.
>

IIRC you define the startup code that's send to the controller. There is
no other negotiations that takes place. IIRC OpenPnP/I&S may send "M115"
to try to identify the controller and suggest configuration settings.

Jan

[vespaman]

lördag 30 mars 2024 kl. 18:24:54 UTC+1 skrev Jan:

On 30.03.2024 17:09, vespaman wrote:
[...]
> I am a little bit worried about the control from OpenPnP, afaict, there
> no way to indicate from OpenPnP if it wants to pick up a new nozzle tip,
> or dispose one.
>

From studying the code I can tell, that each nozzle tip has its own
changer sequence. Each sequence has four way points and can actuate one
actuator between each two. So a total of three actuators can be freely
configured. Actuators are only actuated TRUE/ON. On load, the sequence
is executed in forward direction, on unload backward.

This sounds good, I suppose, then I can add extra "dummy" actuators and use the order of arrival in the controller, to decide if it is a load or unload.

 

[...]
> I think I am unsure about the TCP connection, that is, if OpenPnP
> wants some startup negotiating, but I'll do some tests, tomorrow.
>
IIRC you define the startup code that's send to the controller. There is
no other negotiations that takes place. IIRC OpenPnP/I&S may send "M115"
to try to identify the controller and suggest configuration settings.

Got it! 

Thanks,

 - Micael

[Jonathan Oxer]

My OpenKayo project uses an ESP32 with a GCODE parser to convert messages from OpenPnP into the format required for the original Kayo motion controller.

I'm not much of a coder, but perhaps it's a starting point. I tried to make the parser fairly flexible and extensible:

https://github.com/superhouse/openkayo

Which reminds me, the hardware is well sorted and has been in use in production for a while so I need to update that repo. The firmware is all you care about though.

Cheers

Jon

--

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/2a1fe3af-d456-4e8a-bdfd-488a0853c144n%40googlegroups.com.

[vespaman]

Thanks Jon, I'll have a look at your solution - anything working is useful at this point in time, and if I can avoid to re-invent the wheel, I'm happy.

 - Micael

[Balázs Kiss]

Hi all and happy easter! 

We are trying to implement the maxfeeder auto feeder with esp32 controller. Unfortunatrly, the impressive project have some pcb design drawbacks, which is under development. The esp32 controller is connected via gcode tcp driver and the source is well wrutten and available online. There is a complete guide for implementation in the readme. 

Best regards, 

Balazs

[mark maker]

In addition to what Jan said, you can also use scripts, both on the nozzle tip load/unload events themselves, and on each of the three actuators.

https://github.com/openpnp/openpnp/wiki/Scripting

But it would still be useful to know what you are missing for your kind of changer.

> Actuators are only actuated TRUE/ON.

Frankly, I consider this a bug of the original implementation. We should really fix it ASAP, it should be True for load and False for unload. Those that want the same code can simply enter it twice.

_Mark

[Jan]

On 01.04.2024 11:05, 'mark maker' via OpenPnP wrote:
> /> Actuators are only actuated TRUE/ON. /

>
> Frankly, I consider this a bug of the original implementation. We should
> really fix it ASAP, it should be True for load and False for unload.
> Those that want the same code can simply enter it twice.
>

I just submitted PR #1620.
All users currently using automatic nozzle tip changing, shall verify
that their actuator configuration does not rely on actuators being
actuated TRUE. I'd recommend to remove any TRUE/FALSE dependencies
currently in there.

Jan

> On 30.03.2024 18:24, 'Jan' via OpenPnP wrote:
>> On 30.03.2024 17:09, vespaman wrote:
>> [...]
>>> I am a little bit worried about the control from OpenPnP, afaict,
>>> there no way to indicate from OpenPnP if it wants to pick up a new
>>> nozzle tip, or dispose one. If this is true, this needs to built into
>>> my controller, and I have to make sure they both agree on nozzle tip
>>> status. Or maybe I misunderstood the changer setup, I haven't looked
>>> into that part properly.
>>>
>> From studying the code I can tell, that each nozzle tip has its own
>> changer sequence. Each sequence has four way points and can actuate
>> one actuator between each two. So a total of three actuators can be
>> freely configured. Actuators are only actuated TRUE/ON. On load, the
>> sequence is executed in forward direction, on unload backward.
>>
>> [...]
>> > I think I am unsure about the TCP connection, that is, if OpenPnP
>> > wants some startup negotiating, but I'll do some tests, tomorrow.
>> >
>> IIRC you define the startup code that's send to the controller. There
>> is no other negotiations that takes place. IIRC OpenPnP/I&S may send
>> "M115" to try to identify the controller and suggest configuration
>> settings.
>>
>>     Jan
>>

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

> <mailto:openpnp+u...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/openpnp/42599a90-2144-431d-ab44-5205ca202a3f%40makr.zone <https://groups.google.com/d/msgid/openpnp/42599a90-2144-431d-ab44-5205ca202a3f%40makr.zone?utm_medium=email&utm_source=footer>.

[vespaman]

Excellent, that makes it much cleaner on the receiving side - I don't have to create a state machine to know if it is load or unload.

With this, I don't think that I am missing anything. :-)

Cheers,

 - Micael