biqu bx 3d printer ??

[gene heskett]

Greetings all;

I seem to be having occasional difficulty with microsd cards as sneaker-net
between cura and a biqu bx printer.

So I plugged in an older usb2 boosted extension cable with a 6" micro-usb plug
adapter plugged in between that cable and the teeny usb socket on the front of
the 3d printer.

This is what I get from dmesg:

[ 3345.887506] usb 2-3.4: new full-speed USB device number 6 using xhci_hcd
[ 3345.989042] usb 2-3.4: New USB device found, idVendor=0483, idProduct=5740,
bcdDevice= 2.00
[ 3345.989045] usb 2-3.4: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[ 3345.989047] usb 2-3.4: Product: SKR_SE_BX CDC in FS Mode
[ 3345.989049] usb 2-3.4: Manufacturer: STMicroelectronics
[ 3345.989051] usb 2-3.4: SerialNumber: 386E39623439
[ 3346.001829] cdc_acm 2-3.4:1.0: ttyACM0: USB ACM device
[ 3346.002017] usbcore: registered new interface driver cdc_acm
[ 3346.002017] cdc_acm: USB Abstract Control Model driver for USB modems and
ISDN adapters

So apparently it can talk to the printer but doesn't seem to understand its a
printer.

Is there a Fix? Something I can modprobe on the buster machine?

Thank you and stay well all.

Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

[didier gaumet]

Hello Gene,

If I am not mistaken, using a USB cable between your computer and your
3D printer, it is being viewed by teh OS (Debian) as a mere serial
port.
This is Cura (or another software) that sends appropriate G-code to
this particular 3D printer

[gene heskett]

Yes, that would be my assumption. The printer complains about unk commands
that are the same errors to the printer, like the two aren't speaking the same
baud rate or endiness. As a similar cable plugged into one of my creatlity
printers is found by cura in a couple minutes. But cura isn't finding this
biqu bx.

What utility could adjust the baud and endianess of this tty_ACM0?

And from past experience hooking up creality's junk, I'd say whatever utility
is used to adjust the protocol used, also needs to set a flag that tells udev,
do not touch, which is I think what may be probing it, generating the errors
the printer then complains about.

But this is all new dirt to me. One way to get it right, 69! ways to get it
wrong. :o(

[didier gaumet]

Le mercredi 22 décembre 2021 à 04:36 -0500, gene heskett a écrit :

[...]

> But cura isn't finding this
> biqu bx.
>
> What utility could adjust the baud and endianess of this tty_ACM0?

[...]

Disclaimer: I have never used a 3D printer, and my knowledge of com
port setup is limited to dial-in modems as a user, back in the day...

I would imagine that there is a way in Cura to add and setup a new
printer with a particular com port at the adequate speed. This is
appears to be the case in Repetier-host via a GUI.

And perhaps, if you manage to tell your slicer what com port is to be
used, you can manage this com port the old way:
https://tldp.org/HOWTO/Serial-HOWTO.html

[Tixy]

On Wed, 2021-12-22 at 04:36 -0500, gene heskett wrote:
[...]

> What utility could adjust the baud and endianess of this tty_ACM0?

I can't see how that is relevant, this is your printer's USB connection
not some old style asynchronous serial interface like RS232.

--
Tixy

[gene heskett]

I was not aware of that tutorial, thank you very much.

[didier gaumet]

Le mercredi 22 décembre 2021 à 11:54 +0000, Tixy a écrit :
>
> I can't see how that is relevant, this is your printer's USB
> connection
> not some old style asynchronous serial interface like RS232.
>

Hello Tixy,

Gene is talking about a UDB 3D printer, not about a USB printer, and it
is common for these devices (as for numerous lab devices) to rely on
some form of old-style serial communication, even through USB.

the USB ACM Wikipedia page:
https://en.wikipedia.org/wiki/USB_communications_device_class

[Tixy]

Yes, but there's a difference between a serial style communications
protocol, and a physical serial bus which needs a baud rate etc. to be
set up. I guess it's possible to use a USB to serial chip in the
printer which then talks to a serial interface on the computer driving
the printer. But that is very clunky and surely not a bodge that's been
needed in the past decade given the ubiquitous USB support in SoCs.
OK, let's do a little research...

Googling "biqu bx 3d printer" gets me a review [1] which says the
printer uses "a powerful 400 Mhz STM32H743IIT6 Cortex M7 CPU".

Googling "STM32H743IIT6" gets me supplier [2] linking to a datasheet
[3] which says amongst the many peripherals on that SoC are 2 USB OTG
interfaces, and it even includes the PHY for that.

Also, googling the USB vendor and product IDs Gene gave, shows several
places claiming this is a 'Virtual COM Port' from STMicro (the
manufacturer of the above SoC).

All told, it seems highly probable that the USB connector on the
printer is connected directly to this SoC and not via some intermediate
serial interface which needs a baud rate configuring.

[1] https://3dprintbeginner.com/biqu-bx-review/
[2] https://www.mouser.co.uk/ProductDetail/STMicroelectronics/STM32H743IIT6?qs=FNcb6ahWXRzE163cq8Rfjg%3D%3D
[3] https://www.mouser.co.uk/datasheet/2/389/dm00387108-1799185.pdf

--
Tixy

[didier gaumet]

Ah, dichotomy between what evolution permits and what culture
autorizes: sensible matter nowadays ;-)

It seems to me that you are perfectly right in establishing what are
the technical abilities of either hardware and software involved here.

But Debian detects a /dev/ttyACM0 port which suggests to me this 3D
printer presents itself to the OS as a raw serial com port (tty) albeit
through an USB connection (ACM), probably from compatibility reasons
rather than mere aptitudes: it would then be detected as a
/dev/USBsomething?

But that's only what I understand, perhaps wrongly, and I do not
pretend to be right here, my knowledge is *far* too limited :-)

[Stefan Monnier]

> But Debian detects a /dev/ttyACM0 port which suggests to me this 3D
> printer presents itself to the OS as a raw serial com port (tty) albeit
> through an USB connection (ACM), probably from compatibility reasons
> rather than mere aptitudes: it would then be detected as a
> /dev/USBsomething?

Indeed, many devices present themselves as things like CDC ACM, CDC NCM,
... I assume it's because it's easier for the developers to work with
a communication protocol like RS-232 or like Ethernet (where you can
re-use loads of existing tools and expertise) than with the actual USB
protocol, which is less widely known (and with a less standardized API).


Stefan

[gene heskett]

On Wednesday, December 22, 2021 10:00:24 AM EST didier gaumet wrote:
> Ah, dichotomy between what evolution permits and what culture
> autorizes: sensible matter nowadays ;-)
>
> It seems to me that you are perfectly right in establishing what are
> the technical abilities of either hardware and software involved here.
>
> But Debian detects a /dev/ttyACM0 port which suggests to me this 3D
> printer presents itself to the OS as a raw serial com port (tty) albeit
> through an USB connection (ACM), probably from compatibility reasons
> rather than mere aptitudes: it would then be detected as a
> /dev/USBsomething?
>

Not here on buster. Its /dev/ttyACM0.

> But that's only what I understand, perhaps wrongly, and I do not
> pretend to be right here, my knowledge is *far* too limited :-)

Mine too, zero experience with this sort of a critter. Its definitely /dev/
ttyACM0 when plugged in. Not a USB something.

I note from the web wiki you posted before (thanks) , two things, one being
the mention of prolific, and most of their stuff is busted in odd ways, and it
makes no mention of usb-2 compatibility, which is the case with these off-
lease dell's I use for utility stuff or driving CNC machinery I've built,
Their fastest usb is 2, No blue ports in a 4 pack of them. Its the empty pci-
e slot I'm burning up on those I use for machine control.

'twould be nice if a way to use it for direct drive
was found.

Thanks all.

[Curt]

Apparently it is though, relevant, to a virtual serial port.

https://www.reddit.com/r/MPSelectMiniOwners/comments/7a9zl8/issues_printing_over_usb_in_ubuntulinux/

Maybe the OP could try Octoprint or Pronsole.

[Tixy]

I just read that, very strange if setting a baud rate on a 'virtual'
(i.e. not hardware) serial port makes any difference. Unless the act of
sending the baud rate commands over USB to the printer makes its
software (or Linux) go into some different state where subsequent
printing commands work.

Not knowing really what ACM is I looked for the docs on the internet,
seems ACM is part of the PSTN subclass of USBs Communications Device
Class (CDC) and the docs says:

With an Abstract Control Model, the USB device understands standard
V.250 (AT) commands.

Ahh, AT commands, that brings back memories. :-)

Still none the wiser of what hardware in the printer you would be
setting the baud rate of though, but as I'm ignorant of the insides of
3D printers perhaps that's not a surprise.

--
Tixy

[Curt]

On 2021-12-23, Tixy <ti...@yxit.co.uk> wrote:
>
> Still none the wiser of what hardware in the printer you would be
> setting the baud rate of though, but as I'm ignorant of the insides of
> 3D printers perhaps that's not a surprise.
>

You set the baud rate of the port is how I understand it.

stty -F /dev/ACM0 115200

[Tixy]

Yes, but that just sends an ioctl request to the Linux driver which
looking at the source code [1] translates it into sending control
message to the USB device of type USB_CDC_REQ_SET_LINE_CODING.

So what does the 3D printer do when it receives this control packet?
What _hardware_ is it actually going to change the baud rate of?
I'm assuming here, as I said in my other reply [2], that the USB
interface is connected direct to the SoC running the printer, and not
to some USB serial adaptor which is then wired to the controlling CPU
hardware.

[1] See acm_tty_set_termios() in drivers/usb/class/cdc-acm.c
[2] https://lists.debian.org/debian-user/2021/12/msg00818.html

--
Tixy

[Curt]

On 2021-12-23, Tixy <ti...@yxit.co.uk> wrote:
> On Thu, 2021-12-23 at 14:20 +0000, Curt wrote:
>> On 2021-12-23, Tixy <ti...@yxit.co.uk> wrote:
>> >
>> > Still none the wiser of what hardware in the printer you would be
>> > setting the baud rate of though, but as I'm ignorant of the insides of
>> > 3D printers perhaps that's not a surprise.
>> >
>>
>> You set the baud rate of the port is how I understand it.
>>
>>  stty -F /dev/ACM0 115200
>>
>
> Yes, but that just sends an ioctl request to the Linux driver which
> looking at the source code [1] translates it into sending control
> message to the USB device of type USB_CDC_REQ_SET_LINE_CODING.
>
> So what does the 3D printer do when it receives this control packet?
> What _hardware_ is it actually going to change the baud rate of?
> I'm assuming here, as I said in my other reply [2], that the USB
> interface is connected direct to the SoC running the printer, and not
> to some USB serial adaptor which is then wired to the controlling CPU
> hardware.

I'd think you'd change the baud rate of the port to some value copacetic
to the printer via some negotiated agreement. I wouldn't be able to
provide the technical, material details, I'm afraid. Of course, if you
think this is all some sort of hooey, all I can say is there's oodles of
hooey on the 3d printer technical forums, and I've fallen for it.

:-)

[gene heskett]

I'm not too sure about the latest cura, I've toured the menu's and there is
not a visible item anyplace to configure it to drive a usb port printer
directly. Older versions did have that, but it was a wee mite flaky and would
not reconnect if the printer was powered down while cura was not. If the cable
is plugged in, the /dev/ttyACM0 port is there, so the printer complains about
some spurious AT commands which degenerate later to strings of uNSS.

Its busy ATM, doing parts for a variation of a harmonic drive. At some point
I'll leave it plugged and and live while I restart cura. Maybe cura still has
the same bug its had for quite a few upgrades since 3.00 was new a couple
years back?. When a printer is found, it can alternate between saving the
gcode to disk. or driving the printer directly.

I've installed setserial, but haven't been able to make sense of the --help
screen yet.

Thank you, Merry Christmas to all.

[gene heskett]

On Thursday, December 23, 2021 9:07:56 AM EST Tixy wrote:
> On Thu, 2021-12-23 at 13:22 +0000, Curt wrote:
> > On 2021-12-22, Tixy <ti...@yxit.co.uk> wrote:
> > > On Wed, 2021-12-22 at 04:36 -0500, gene heskett wrote:
> > > [...]
> > >
> > > > What utility could adjust the baud and endianess of this tty_ACM0?
> > >
> > > I can't see how that is relevant, this is your printer's USB connection
> > > not some old style asynchronous serial interface like RS232.
> >
> > Apparently it is though, relevant, to a virtual serial port.
> >
> > https://www.reddit.com/r/MPSelectMiniOwners/comments/7a9zl8/issues_printin
> > g_over_usb_in_ubuntulinux/
> >
> > Maybe the OP could try Octoprint or Pronsole.
>
> I just read that, very strange if setting a baud rate on a 'virtual'
> (i.e. not hardware) serial port makes any difference. Unless the act of
> sending the baud rate commands over USB to the printer makes its
> software (or Linux) go into some different state where subsequent
> printing commands work.
>
> Not knowing really what ACM is I looked for the docs on the internet,
> seems ACM is part of the PSTN subclass of USBs Communications Device
> Class (CDC) and the docs says:
>
> With an Abstract Control Model, the USB device understands standard
> V.250 (AT) commands.
>
> Ahh, AT commands, that brings back memories. :-)

Not always fond memories, every modem maker had their own interpretation of
the Hayes cmd set.

> Still none the wiser of what hardware in the printer you would be
> setting the baud rate of though, but as I'm ignorant of the insides of
> 3D printers perhaps that's not a surprise.

There's an echo here too.

Thanks all and Merry Christmas to all.

[gene heskett]

More than likely it also needs an 8n1 or similar size,parity and stop bit
length.

I'll do some experimenting when the printer isn't busy.

Thanks & Merry Christmas all.

[gene heskett]

And I'm happy to report that restarting cura found the printer so I'm trying
it out now. :o)

Merry Christmas all.

[David]

On Thu, 23 Dec 2021 at 00:50, Tixy <ti...@yxit.co.uk> wrote:

Hi Tixy,

After reading your several musings in this thread regarding
USB verses serial interfaces for CNC machines (3D printer, etc),
I thought I'd respond, because I think they are missing the mark.

> I guess it's possible to use a USB to serial chip in the
> printer which then talks to a serial interface on the computer driving

> the printer. But that is very clunky ...

I have a budget 3 axis CNC router and that's exactly how it operates.
Apart from that, I'm not involved with the CNC world, but I get the
impression that this is standard practice at all scales, for historical
and practical reasons.

I'd suggest that this is because for CNC applications, USB is not
better than a UART serial interface, and probably worse. So CNC
machine designers would have begun with serial interfaces before
USB was invented, and then had no reason to change to USB.

Reasons that occur to me:

- USB has poorer noise immunity (don't forget that a CNC machine
contains several motors and is often used in industrial settings
which can be electrically noisy). And in CNC, anything going
wrong typically produces some kind of disaster of a catastrophic,
unsafe and expensive nature.

- USB has maximum cable length specification of only a few
metres (so wikipedia says).

- USB is optimised towards higher data rates.
In general a CNC machine receives one small file of G-code, and
then autonomously fabricates an item. It is irrelevant if the file
transfer takes seconds, when the mechanical job takes minutes.

- CNC machines aren't mass consumer items, so they
don't need to follow fashion.

[gene heskett]

No, time is money, so the emphasis is on what does or does not work. Sometimes
you find dependability in the strangest places.
>
This is also true, and the market is full of very expensive proprietary
solutions. Solutions that both limit what the machine can do, and that also
means that many are short term solutions when support disappears when that
vendor/maker disappears with the last $100 in the company's account. That more
often than not leaves a business that bought that $200,000 machine with 19
tons of scrap cast iron that is useless when the first $2 transistor fails.
And it may be only half paid for.

Enter, stage left, an electronics expert with an install cd for LinuxCNC in
his hand, which is free and has people all over this planet doing the
engineering needed to figure out how to rip out the proprietary stuff and
rework that dead machine, more than likely making it do things it never did
before and faster to boot. As long as the shop owner understands linux and
linuxcnc are free, but the guy who comes in to make it work and does expects
to be paid for his time and know how.

And its under very rapid development to further improve it with 10 or more
github commits a week. And we've got the cream of the coders working on it.
They have a stable version that's updated maybe annually, and the bleeding
edge, will eventually be the next version being built by a buildbot, sometimes
2 or 3 times a day. I run the bleeding edge stuff on 4 machines here and in 10
years, its bit me twice, but the fix is in the next download, or I sometimes
pull the github version and build it with my own buildbot. But I have a leg or
two up on the mechanics, as I am a CET, who worked as a broadcast engineer
since 1963, keeping a tv station on the air someplace n this great country
withthe last 18 years I worked as the CE at the local CBS affiliate. So even
at 87 yo, and an 8th grade education, the electronics involved are a piece of
cake for me.

That brings me back to "the strangest places" remark above. I wanted to see if
I could run one of my machines on an rpi3. But all it has is a plethora of
gpio pins. A swedish prof took that problem and wrote an SPI driver for us. A
famously ticklish thing but with a 3 wire com, sending data out at about 42
megabaud, the receiving the fpga output back at 25 megabaud, expands to 72 i/o
pins to run machines with. And unless the pi is also running firefox, problem
to response time is around 12 microseconds. And I was first. And it Just
Works, doing things with that lathe it couldn't do new, and 4 or 5 times
faster than I could turn the cranks.

[Tixy]

On Fri, 2021-12-24 at 10:41 +1100, David wrote:
> On Thu, 23 Dec 2021 at 00:50, Tixy <ti...@yxit.co.uk> wrote:
>
> Hi Tixy,
>
> After reading your several musings in this thread regarding
> USB verses serial interfaces for CNC machines (3D printer, etc),
> I thought I'd respond, because I think they are missing the mark.
>
> > I guess it's possible to use a USB to serial chip in the
> > printer which then talks to a serial interface on the computer driving
> > the printer. But that is very clunky ...
>
> I have a budget 3 axis CNC router and that's exactly how it operates.
> Apart from that, I'm not involved with the CNC world, but I get the
> impression that this is standard practice at all scales, for historical
> and practical reasons.

You have more experience than me, so am happy to accept this as a more
accurate view than mine :-) Though to not give up in the specific case
of the $subject printer, it would seem perverse for this Kickstarter
funded project to not use the USB interface built into the SoC they are
using and instead add extra silicon for USB.

As a footnote, I have two devices myself where there is an FTDI USB to
serial interface chip built into a device to provide USB connectivity.
One is a Shevaplug which has a circa 15 year old SoC in it. The second
is my own 8-bit computer system :-) though this is using the chip
version that provide an 8-bit parallel interface to the FIFO, so
setting baud rate on that device has no effect.

--
Tixy