I don't see M114 being sent in the trace. It seems serial dies on
us before that even happens.
Do you use a Smoothie clone? They have been known to be unstable
But I can't think of any reason why this would be related to the
OpenPnP version. Have you also upraded the Smoothie firmware at
the same time?
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/42c6c834-d444-4dd1-bafe-805f5dea37a6n%40googlegroups.com.
For best capabilities you need my firmware:
But we only support it for original Smoothieboards and some of the good clones. See the cautionary note and links here:
I don't think this is a Smoothieware firmware.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/2888507f-e0ae-4a09-9ee0-88a96e575614n%40googlegroups.com.
There is no response from the serial, so we have to assume
communication does not work.
What does Issues & Solutions say?
And please answer my other question.
Q> Do you use a Smoothie clone? They have been known to be unstable like that.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/27f16e06-4cf2-44ca-aa00-138289dfdef9n%40googlegroups.com.
> mark, I went back to version JULY 31 2021.
I assume you mean OpenPnP, right?
> So, it is NOT communication problem. You should know better than everyone what is the difference with the new revision that might cause such error.....
I'm just a contributor among several, and this is an Open Source project, so you should not jump to such "personalized" conclusions. 🤔
It could still be a communication problem, and a bug in OpenPnP
too. There have been changes since July 2021. Although looking at
these, there are no obvious explanations:
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/be853eb5-cc68-4859-ab6b-79cd3e467dddn%40googlegroups.com.
Hi Bing Luo,
I resend this in the open group, as this should be published, due
to Open Source / OSHW
> I made the board that Benny uses. I confirm that good components and PCBs have been used, with an outer copper thickness of 2 oz and an inner copper thickness of 1 oz.
Thanks for the clarification.
> I only changed the driver to an updated TMC2209.
Sounds good! 😎
Where is the schematic published (OSWH)? Some photos would be
> The serial port wires have also undergone impedance matching
Just to be sure, you mean USB, right?
> Due to its ability to work stably for a long time in older versions of OpenPNP, Benny's problem may really be related to the software version.
The topic says "moving from openpnp 1 to 2". Was he really using
version 1 before? This is very old!
There are also optimization options in the newer version that
fundamentally change how serial communication works. Older
versions (and legacy options) use simple unidirectional ping-pong
comms (Confirmation Flow Control, i.e. waiting for each "ok"). Now
the comm is asynchronous full-duplex and comes in bursts. For
instance, hardware flow control becomes very important, while it
probably did not matter before.
If you haven't changed the hardware there, and used genuine
parts, it should not matter, though.
@Benny, I just wanted to check that aspect in your JULY 31
2021 version log, but I can't because it is not the full log.
Please always send the full log from now on! Also note that the
last 100 logs are archived, so you could still send me that log
(check the timestamps).
> But only you can find out the truth.
As I explained, I'm just one OpenPnP contributor. And
frankly, it would be very strange for something so fundamental to
for all Smoothieboards since July 2022, and nobody reported it! So
we should keep an open mind.
When Benny sends the full log/machine.xml, I will have a look, but because of work, it might be the day after tomorrow._Mark
> sch and pcb are in https://github.com/microsmt/Microsmt-PNP-hardware,
Very good, thank you. Nicely documented.
I was missing the "bing luo" --> "microsmt" link, therefore I did not find it. Surely you have communicated this before, but I can't keep everything in my head, sorry (and I'm generally bad with given names). 😅
Ben, when I was talking about "
Smoothie ripoff clones" I was talking about products that do not
Open Source publish the schematic and therefore break the OSHW
license, that use subspec, wrong or counterfeit parts, that use
the Smoothieboard logo without authorization, and/or even make
completely identical-looking (i.e. counterfeit) Smoothieboards,
but with thin copper etc. It's very sad, but all this does
Clearly, the microsmt board is not one of these!
I'm not a lawyer but may I suggest a few things? I think the shop should link to the microsmt Github repo, credit Smoothieware, and state the CERN Open Hardware Licence v1.2 here:
I hope we will find the bug soon. In case it was not yet crystal
clear: I'm open-minded towards the bug being in OpenPnP, I even
listed the PRs that might be involved. At this point I'm just not
ruling out it could be something different too, that's all.
Just to mention one possibility for a an electrical problem that
could be on the user side. I don't think this is the case
here, but just to mention it:
According to me, we should all run the USB controllers with USB isolators. The Smoothieboard derivate I use on my machine has one built-in:
If I'd ever design a controller, I would do the same. We have
large, fast-accelerating machines with heavy heads and portals,
these can drain and back-generate a lot of current (relatively
speaking), which, when grounding/earthing is not perfect, can
create significant ground-bounce. USB is not level shifted, it can
easily be seen how it could fail between a computer and the board.
This is not the same as 3D printing, where you can get away
without an isolator, either because we're printing from SD cards,
or because the machines are smaller, lighter and
But again: that's not an excuse to not look into the
software side, and when I have the full logs I can better do
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/e6458997-d111-4914-93ee-bbfbf11cb617n%40googlegroups.com.
Ben, it's all linked on the OpenPnP page:
The code is linked as one of the top "tabs" in the blue band.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/f93cd85f-6554-47a3-aef1-15f3f42ea57en%40googlegroups.com.
I just wanted to ask for progress here, then noted that my message somehow did not go through, or maybe I even got interrupted before sending it (there were some emergencies at work). Sorry about that 🙁
So I'll rewrite it here:
As you noted yourself, you do have communication errors in both versions. And yes it is expected and also correct that the new version will react more strictly to it. Again I refer to several PRs were this was done:
Now the question is, why this communication error
happens? How can we fix it?
There is one command in your CONNECT_COMMAND
that I'm sure is not needed: M82, an
"extruder only" command and if you configured the controller
right, there are no extruders,
i.e. your config.txt should not
contain extruder stuff like the documented here:
I repeat: your config.txt should not
contain it. If you find that stuff, remove or uncomment it.
Now M82 should still not crash because of that, obviously, but who knows? I suggest you remove it from the CONNECT_COMMAND.
I don't have high hopes this will solve the problem, frankly, but
first things first.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/3301a81f-d404-7687-6dea-18a2767cda6d%40makr.zone.
thank you for your offer.
First, rest assured, that I believe your board is well made. 😁
The error at hand (read errors when connecting) I see in your log
too, though, so the next step would be for me to test with my
other Smoothie derivative board I have here. Maybe it now happens
with all the Smoothies for some reason... ?
If you intend to make and distribute these boards routinely, then it might make sense to send me one. But if this is just a small series, then I think that board would be better off driving another user's OpenPnP machine 😎
In any case, you should know I will only use it on my test rig,
typically with one naked stepper attached, just to test basic
functionality. My testing is more about firmware than about
hardware. Debugging, function testing and timing over USB. It is
not a realistic stress test in terms of electrical robustness etc.
I already have one Smoothie derivative, so your board would be a
bit redundant in these terms. However if you still prefer to get a
test, I would do it.
Do I have time? Not in the sense of a professional schedule, I'm
doing this in my spare time. But I guess I would be able to test
your board within a week or two of receiving it (except over the
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/7724eed5-a5ab-4c57-8152-3578bb323857n%40googlegroups.com.
Appreciate the report! Glad it now works.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/88297ecc-8cb1-4dc8-a435-f4118110947bn%40googlegroups.com.