""^FIRMWARE.*" read error" at Detecting firmware

854 views
Skip to first unread message

Fab

unread,
Feb 17, 2021, 12:18:02 PM2/17/21
to OpenPnP
Hey guys,
I'm recently working on my first PNP and hope you can help me with an issue.

My problem is that I get the error message ""^FIRMWARE.*" read error..." when I click on the "Detect Firmware" button in the driverSettings of my GcodeAsyncDriver.

My setup so far:
  • I flashed the Mainboard (an MKS BASE v1.3) with the recommended (5 axis version) smoothieware from here https://makr.zone/smoothieware-new-firmware-for-pnp/500/
  • The config.txt is setup and works with repetier host.
  • In reptier host the board answers to a M115 request with the following string: FIRMWARE_NAME:Smoothieware, FIRMWARE_URL:http%3A//smoothieware.org, X-SOURCE_CODE_URL:https%3A//github.com/markmaker/Smoothieware/tree/feature/best-for-pnp, FIRMWARE_VERSION:feature/best-for-pnp-c82d0b45, X-FIRMWARE_BUILD_DATE:Oct 22 2020 21:21:58, X-SYSTEM_CLOCK:100MHz, X-AXES:5, X-PAXES:5, X-GRBL_MODE:0, X-CNC:0, X-MSD:1, X-WARNING:deprecated_MCU
  • With the "official" latest smoothieware it is possible to detect the firmware
Do you have any Idea what I did wrong or what else I can try? :)

Thanks a lot for your help and any hints.
Best regards
Fab


ma...@makr.zone

unread,
Feb 17, 2021, 12:31:44 PM2/17/21
to ope...@googlegroups.com

Hi Fab

First some ideas:

  • You might wanna check the connect wait time. It must be surprisingly high for Smoothieware. I don't know why (but this is not new). 
  • Switch off keep-alive. It tends to do funny things with connections, especially on Windows where a COM port can be completely "hung" for the whole system if not closed.

Now some background. There are two modes when the firmware is detected.

  1. When you have the machine disabled: it will then try to connect using the connections settings of the driver, try to detect (using M115) and disconnect again.
  2. When you have the machine enabled:it is then already connected and will just do the detection.

And some questions:

  • Does it fail in both modes?
  • As to the difference between my firmware version and the "official" one. Is this really reproducible? In both modes?
  • What happens, if you enable (connect) the machine and go to the driver Console and just enter M115?
If this does not lead to a solution, set logging level to TRACE and then send the log please.

_Mark

--
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/c49d6122-75dd-444f-bcbd-f8b4395b550dn%40googlegroups.com.

Fab

unread,
Feb 17, 2021, 1:12:29 PM2/17/21
to OpenPnP
Hey Mark,

thanks for your quick answer. :)
I applied the following settings:
  • Deactivated "Keep Alive"
  • Set "Command Timeout" and  "Connect Wait Time" to 3000ms each
  • Deactivated all the other checkbox-options on the "Driver Settings"-Tab
Results:
  • mentioned openPNP-smoothiware version:
    • "Detect Firmware" with disabled machine: same issue
    • "Detect Firmware" with enabled machine: same issue
    • Entering "M115": no response (console window empty, command line input field contains "M115" also after click on "send", btw: openPnp-version: 2021-02-04_06-49-15.d539596)
  • "Official" smoothieware: (https://github.com/Smoothieware/Smoothieware/blob/edge/FirmwareBin/firmware.bin ; config.txt not changed)
    • "Detect Firmware" with disabled machine: response: FIRMWARE_NAME:Smoothieware, FIRMWARE_URL:http%3A//smoothieware.org, X-SOURCE_CODE_URL:https://github.com/Smoothieware/Smoothieware, FIRMWARE_VERSION:edge-6a3b837, X-FIRMWARE_BUILD_DATE:Aug 28 2020 22:01:51, X-SYSTEM_CLOCK:100MHz, X-AXES:5, X-GRBL_MODE:0, X-CNC:0, X-MSD:1, X-WARNING:deprecated_MCU
    • "Detect Firmware" with enabled machine: response: FIRMWARE_NAME:Smoothieware, FIRMWARE_URL:http%3A//smoothieware.org, X-SOURCE_CODE_URL:https://github.com/Smoothieware/Smoothieware, FIRMWARE_VERSION:edge-6a3b837, X-FIRMWARE_BUILD_DATE:Aug 28 2020 22:01:51, X-SYSTEM_CLOCK:100MHz, X-AXES:5, X-GRBL_MODE:0, X-CNC:0, X-MSD:1, X-WARNING:deprecated_MCU
    • Entering "M115": response: Smoothie
      ok
      ok
      ok
      > M115
      FIRMWARE_NAME:Smoothieware, FIRMWARE_URL:http%3A//smoothieware.org, X-SOURCE_CODE_URL:https://github.com/Smoothieware/Smoothieware, FIRMWARE_VERSION:edge-6a3b837, X-FIRMWARE_BUILD_DATE:Aug 28 2020 22:01:51, X-SYSTEM_CLOCK:100MHz, X-AXES:5, X-GRBL_MODE:0, X-CNC:0, X-MSD:1, X-WARNING:deprecated_MCU
      ok
I did also attach my config file.

Thanks a lot for your help. :)
Best regards
Fab
config.txt

ma...@makr.zone

unread,
Feb 17, 2021, 1:28:31 PM2/17/21
to ope...@googlegroups.com

Hi Fab,

That's really strange. Is there any response at all using OpenPnP i.e. to other commands?

Can you send a log? (Trace level)

_Mark

Fab

unread,
Feb 17, 2021, 1:37:00 PM2/17/21
to OpenPnP
Hi Mark,
Mh, from my pointof view there is no communication at all. Following the log output: (didn't knew about this)

2021-02-17 19:32:22.347 GcodeAsyncDriver DEBUG: serial://COM5 commandQueue.offer(G21 ; Set millimeters mode, 30000)...
2021-02-17 19:32:22.347 GcodeDriver$ReaderThread TRACE: [serial://COM5] << Smoothie
2021-02-17 19:32:22.347 GcodeAsyncDriver DEBUG: serial://COM5 commandQueue.offer(G90 ; Set absolute positioning mode, 30000)...
2021-02-17 19:32:22.347 GcodeAsyncDriver DEBUG: serial://COM5 commandQueue.offer(M115, 30000)...
2021-02-17 19:32:22.347 GcodeAsyncDriver$WriterThread TRACE: [serial://COM5] >> G21 ; Set millimeters mode
2021-02-17 19:32:22.347 GcodeDriver$ReaderThread TRACE: [serial://COM5] << ok
2021-02-17 19:32:22.348 GcodeDriver TRACE: [serial://COM5] confirmed G21 ; Set millimeters mode
2021-02-17 19:32:22.349 GcodeAsyncDriver$WriterThread TRACE: [serial://COM5] >> G90 ; Set absolute positioning mode
2021-02-17 19:32:22.349 GcodeDriver$ReaderThread TRACE: [serial://COM5] << WARNING: This is not a sanctioned board and may be unreliable and even dangerous. This MCU is deprecated, and cannot guarantee proper function
2021-02-17 19:32:22.349 GcodeDriver$ReaderThread TRACE: [serial://COM5] << ok
2021-02-17 19:32:22.349 GcodeDriver TRACE: [serial://COM5] confirmed G90 ; Set absolute positioning mode
2021-02-17 19:32:22.349 GcodeDriver$ReaderThread TRACE: [serial://COM5] << ok
2021-02-17 19:32:22.350 GcodeAsyncDriver$WriterThread TRACE: [serial://COM5] >> M115
2021-02-17 19:32:22.352 GcodeDriver$ReaderThread TRACE: [serial://COM5] << FIRMWARE_NAME:Smoothieware, FIRMWARE_URL:http%3A//smoothieware.org, X-SOURCE_CODE_URL:https%3A//github.com/markmaker/Smoothieware/tree/feature/best-for-pnp, FIRMWARE_VERSION:feature/best-for-pnp-c82d0b45, X-FIRMWARE_BUILD_DATE:Oct 22 2020 21:21:58, X-SYSTEM_CLOCK:100MHz, X-AXES:5, X-PAXES:5, X-GRBL_MODE:0, X-CNC:0, X-MSD:1, X-WARNING:deprecated_MCU
2021-02-17 19:32:22.353 GcodeDriver$ReaderThread TRACE: [serial://COM5] << ok
2021-02-17 19:32:22.355 GcodeAsyncDriver DEBUG: serial://COM5 commandQueue.offer(M114, 30000)...
2021-02-17 19:32:22.355 GcodeDriver TRACE: [serial://COM5] confirmed M115
2021-02-17 19:32:22.356 GcodeAsyncDriver$WriterThread TRACE: [serial://COM5] >> M114
2021-02-17 19:32:22.357 GcodeDriver$ReaderThread TRACE: [serial://COM5] << ok C: X:0.0000 Y:0.0000 Z:0.0000 E:0.0000
2021-02-17 19:32:22.471 GcodeAsyncDriver$WriterThread TRACE: [serial://COM5] disconnectRequested, bye-bye.
2021-02-17 19:32:22.873 GcodeDriver$ReaderThread TRACE: [serial://COM5] disconnectRequested, bye-bye.
2021-02-17 19:32:59.091 ReferenceMachine DEBUG: setEnabled(true)
2021-02-17 19:33:29.109 GcodeDriver$ReaderThread ERROR: Read error
2021-02-17 19:33:29.109 GcodeAsyncDriver DEBUG: serial://COM5 commandQueue.offer(G21 ; Set millimeters mode, 30000)...
2021-02-17 19:33:29.109 GcodeAsyncDriver$WriterThread ERROR: Write error on serial://COM5: java.io.IOException: Write error.
2021-02-17 19:33:29.109 GcodeAsyncDriver DEBUG: serial://COM5 commandQueue.offer(G90 ; Set absolute positioning mode, 30000)...
2021-02-17 19:33:31.222 ReferenceMachine DEBUG: homing machine
2021-02-17 19:33:31.223 MessageBoxes DEBUG: Error: java.lang.Exception: serial://COM5 IO Error on reading from the controller.
2021-02-17 19:33:35.484 GcodeDriverSolutions WARNING: GcodeAsyncDriver failure to detect firmware

Actually I managed to get one valid (looking) response. The only thing I did change was the "second_usb_serial_enable" feature from true to false.
But the connection seems to be unstable. I wasnt realy able to connect to the machine and start an homing. 
Can this be related to an usb hub that is hooked between my computer and the board?

Thanks and best regards
Fab

Fab

unread,
Feb 17, 2021, 1:49:12 PM2/17/21
to OpenPnP
...so i tried the following steps:
  • switch to on usb cable between my computer and the board
  • restarted openPNP
This time I get the error "serial://COM5 IO Error on reading from the controller." Connecting from repetier host is still possible. Not sure if this is helpfull.
Also please see the log:
2021-02-17 19:44:40.750 Main INFO: Bienvenue, Bienvenido, Willkommen, Hello, Namaskar, Welkom, Bonjour to OpenPnP version 2021-02-04_06-49-15.d539596.
2021-02-17 19:44:40.755 Scripting TRACE: Scripting.on Startup
2021-02-17 19:44:40.810 OpenPnpCaptureCamera WARNING: No camera found with ID HBV HD CAMERA \\?\usb#vid_0ac8&pid_0346&mi_00#7&33dcb60b&0&0000#{65e8773d-8f56-11d0-a3b9-00a0c9223196}\global for camera Downlooking Cam
2021-02-17 19:44:40.924 OpenPnpCaptureCamera WARNING: No camera found with ID HBV HD CAMERA \\?\usb#vid_0ac8&pid_0346&mi_00#6&1e3a45bb&1&0000#{65e8773d-8f56-11d0-a3b9-00a0c9223196}\global for camera Uplooking Cam
2021-02-17 19:44:40.925 CameraView DEBUG: Failed to load camera specific reticle, checking default.
2021-02-17 19:44:40.929 CameraView DEBUG: No reticle preference found.
2021-02-17 19:45:25.333 GcodeDriver$ReaderThread ERROR: Read error
2021-02-17 19:45:25.333 GcodeAsyncDriver DEBUG: serial://COM5 commandQueue.offer(G21 ; Set millimeters mode, 30000)...
2021-02-17 19:45:25.334 GcodeAsyncDriver$WriterThread ERROR: Write error on serial://COM5: java.io.IOException: Write error.
2021-02-17 19:45:25.334 MessageBoxes DEBUG: Error: java.lang.Exception: serial://COM5 IO Error on reading from the controller.
2021-02-17 19:45:28.738 ReferenceMachine DEBUG: setEnabled(true)
2021-02-17 19:45:58.744 GcodeDriver$ReaderThread ERROR: Read error
2021-02-17 19:45:58.744 GcodeAsyncDriver DEBUG: serial://COM5 commandQueue.offer(G21 ; Set millimeters mode, 30000)...
2021-02-17 19:45:58.745 GcodeAsyncDriver$WriterThread ERROR: Write error on serial://COM5: java.io.IOException: Write error.
2021-02-17 19:45:58.745 MessageBoxes DEBUG: Enable Failure: serial://COM5 IO Error on reading from the controller.
2021-02-17 19:46:28.763 GcodeDriver$ReaderThread ERROR: Read error
2021-02-17 19:46:28.763 GcodeAsyncDriver DEBUG: serial://COM5 commandQueue.offer(G21 ; Set millimeters mode, 30000)...
2021-02-17 19:46:28.763 MessageBoxes DEBUG: Error: java.lang.Exception: serial://COM5 IO Error on reading from the controller.
2021-02-17 19:46:28.763 GcodeAsyncDriver$WriterThread ERROR: Write error on serial://COM5: java.io.IOException: Write error.
2021-02-17 19:48:12.729 GcodeDriver$ReaderThread ERROR: Read error
2021-02-17 19:48:12.729 GcodeAsyncDriver DEBUG: serial://COM5 commandQueue.offer(G21 ; Set millimeters mode, 30000)...
2021-02-17 19:48:12.730 GcodeAsyncDriver$WriterThread ERROR: Write error on serial://COM5: java.io.IOException: Write error.
2021-02-17 19:48:12.730 MessageBoxes DEBUG: Error: java.lang.Exception: serial://COM5 IO Error on reading from the controller.

Thanks and best regards
Fab

ma...@makr.zone

unread,
Feb 17, 2021, 2:03:50 PM2/17/21
to ope...@googlegroups.com

Hi Fab,

When you say "offical" do you mean MKS specific firmware or the original Smoothieware firmware?

Do you get the same "WARNING: This is not a sanctioned board and may be unreliable and even dangerous. This MCU is deprecated, and cannot guarantee proper function"?

Actually, let's stop right here... I will not spend my spare time trying to support a board from a manufacturer that is known to be a bad parasite of Open Source projects and uses sup-par components to save a few cents, knowing it will cause problems down the road.

I assume you didn't know when you bought it and you are now a victim too. I'm sorry about this. But please buy one of the products adhering to Open Source principles. These principles are very important to me, they are the only thing that "pay" for my efforts here.

I hope others learn something from it.

_Mark

Fab

unread,
Feb 17, 2021, 2:14:50 PM2/17/21
to OpenPnP
Hi Mark,
  • I flashed the latest (stable) release from the smoothieware repository. This one here: https://github.com/Smoothieware/Smoothieware/blob/edge/FirmwareBin/firmware.bin
  • Yes i get the same warning with this release. I was also suspicious about this and found a discussion somehwere (sorry dont find the link anymore) where also some other people with the original smoothieboard from the first kickstater batch were complaining about this. It looks like they changed from the LPC1768 to the LPC1769 MCU and marked the LPC1768 as deprecated. Maybe a marketing move to put the china clones in there (earned) bad light. At least that was the asumption there...
  • I'm totaly with you. Actually I didnt order this board especially for this purpose. (Had it lying around from a project i postponed a few years ago when I wasnt really aware about this situation with smoothieware) Thats also the reason why i'm using this pretty old board. Would be willing to buy a new one. Do you have any recommendations? Checked the recommended boards in the openPnp wiki but (if i remember right) most of the links were dead. :/
Thanks anyways for your help and your support about this awesome project in general :)
Best regards
Fab

ma...@makr.zone

unread,
Feb 18, 2021, 2:53:59 AM2/18/21
to ope...@googlegroups.com

Hi Fab,

> I flashed the latest (stable) release from the smoothieware repository.

That discrepancy is in-deed strange.

As you might have read, I'm not using the latest version as the basis of my fork, because it does not seem to work with 6-axis endstops (even the unchanged original does not boot on my machine). But maybe there is a bug-fix somewhere in that time span that causes this.

I will keep this on the radar. Not for the MKS boards but for the others.

> I'm totaly with you.

I'm glad to hear that. :-)

> Checked the recommended boards in the openPnp wiki but (if i remember right) most of the links were dead. :/

Yes, that is in deed a problem. The controller or more specifically the SPI controlled drivers (the TMC2660 bigfoots) I spent a lot of time optimizing, seem also not available anymore:

https://makr.zone/choosing-a-motion-controller-the-panucatt-azteeg-x5-gt-32bit/455/

> Do you have any recommendations?

It depends...

A)

If you're open to change the lineage, the Duet 3D 3 series is very nice. But also quite expensive, as it contains a lot of extras that are not (usually) needed on a PnP. On the other hand, as far as I can tell, it is really done very solid: high voltages (important for PnP!), high currents, all secondary voltages properly generated (DC-DC).

With firmware 3.3beta that is scheduled to be released very soon, it supports all the important OpenPnP Advanced Motion Control features. 

In this firmware see the power both in hardware and in active development to bring even more advanced features in the future. It is IMHO a shining example of how Open Source is combined with professional commercial operation. And it is open for contributions (which sadly cannot be said for Smoothieware).

B)

If you want to remain on the Smoothie path, I recommend mailing to Arthur directly to obtain an original board. <wolf....@gmail.com>

C)

There are other options if you are more adventurous:

Bill's Marlin on a Teensy 4.1 works right now, but also could have a lot of potential as a hardware platform for future development, as this MCU is very powerful in deed. In fact if only I had more time...

https://github.com/openpnp/openpnp/wiki/Motion-Controller-Firmwares#marlin-20

Jarosław Karwik custom controller (still work in progress). That controller aims to support true 3rd order control, which I think would be really, really useful for OpenPnP, especially for true DIY machines (i.e. those that are mechanically not so super-stiff ... and still wanna go fast!).

https://groups.google.com/g/openpnp/c/oRY0dIKeIDw/m/ONzp3eI4BAAJ

_Mark

Reply all
Reply to author
Forward
0 new messages