FYI, the android software, talks about banka configuration,
perso I think it is the technical name of the driver/module , like balor or GRBLDevice mentioned in the some configuration files … .
The Lightburn doc site says:
BSL Galvo laser
Cypress driver
SEA-LASER usb device
04b4:1004 → FX2LP , there are a couple of generic drivers for linux around
I found this for debian, but I am too “shy” to try anything, it s a more than 2000€ machine !
root@unit01:~# cycfx2prog --help
Usage: cycfx2prog [-d=BUS.DEV] [id=VV.PP[.N]] [commands…]
Options:
–help print this and then exit
–version print version information and then exit
–list list devices and busses and then exit
-d=BBB.DDD set device to use e.g. 006.003; if not specified, first
unconfigured Cypress FX2 is used. Use --list to get BBB
and DDD (bus and device number, not ID).
-id=VV.PP[.N] set vendor and product ID in hex; default 04b4.8613 for
unconfigured FX2. N is the n-th device to use, default 0.
Commands: Must be specified after all options.
reset reset 8051 by putting reset low
run start the 8051 by putting reset high
prg:FILE program 8051; FILE is an Intel hex file (.ihx); will
reset the 8051 before download; use “run” afterwards
delay:NN make a delay for NN msec
set:ADR,VAL set byte at address ADR to value VAL
dram:ADR,LEN dump RAM content: LEN bytes starting at ADR
dbulk:EP,L[,N] bulk read N (default: 1) buffers of size L from endpoint
EP (1,2,4,6,8) and dump them; L<0 to allow short reads
sbulk:EP,STR send string STR as bulk message to endpoint EP (1,2,4,6,8)
fbulk:EP,FILE[,CS] send FILE as bulk message to endpoint EP (1,2,4,6,8)
stdin if no file specified; chunk size CS with default 64
bench_bulk:EP,L[,CS] bench reading L bytes from endpoint EP (chunk size CS)
NOTE: This uses libusb and is slow on the host side!
altif:[IF] set alt interface for next bulk IO; none for FX2 default
ctrl:TYPE,REQUEST[,VALUE[,INDEX]] send a zero-length control message
Cypress FX2(LP) programmer tool v0.47 copyright (c) 2006–2009 by Wolfgang Wieser
root@unit01:~# cycfx2prog --list
Bus 004 Device 001: ID 1d6b:0003
Bus 003 Device 001: ID 1d6b:0002
Bus 002 Device 004: ID 0bda:0411
Bus 002 Device 003: ID 05e3:0625
Bus 002 Device 002: ID 05e3:0625
Bus 002 Device 001: ID 1d6b:0003
Bus 001 Device 017: ID 04b4:1004 ←———
Bus 001 Device 011: ID 32c2:0064
Bus 001 Device 010: ID 2341:0043
Bus 001 Device 009: ID 046d:c31c
Bus 001 Device 008: ID 0bda:5411
Bus 001 Device 007: ID 8087:0aaa
Bus 001 Device 006: ID 0483:3748
Bus 001 Device 005: ID 05e3:0610
Bus 001 Device 004: ID 0483:374b
Bus 001 Device 003: ID 413c:301d
Bus 001 Device 002: ID 05e3:0610
Bus 001 Device 001: ID 1d6b:0002
root@unit01:~# find /dev/usb/
/dev/usb/
/dev/usb/hiddev1
/dev/usb/hiddev0
root@unit01:~# find /dev/bus/usb/
/dev/bus/usb/
/dev/bus/usb/004
/dev/bus/usb/004/001
/dev/bus/usb/003
/dev/bus/usb/003/001
/dev/bus/usb/002
/dev/bus/usb/002/004
/dev/bus/usb/002/003
/dev/bus/usb/002/002
/dev/bus/usb/002/001
/dev/bus/usb/001
/dev/bus/usb/001/017
/dev/bus/usb/001/011
/dev/bus/usb/001/010
/dev/bus/usb/001/009
/dev/bus/usb/001/008
/dev/bus/usb/001/007
/dev/bus/usb/001/006
/dev/bus/usb/001/005
/dev/bus/usb/001/004
/dev/bus/usb/001/003
/dev/bus/usb/001/002
/dev/bus/usb/001/001
root@unit01:~# ls -l /dev/bus/usb/001/017
crw-rw-r-- 1 root root 189, 16 1 janv. 16:01 /dev/bus/usb/001/017
Hmmm, mk does only support BJJCZ based controller - in essence devices that are supported by ezcad2.
The underlying FPGA might be identical but that’s probably not enough.
So chances to support this device are low, unless someone with a machine and some wireshark experience can help / someone is willing to donate a machine
I think I reverse engineered the EzCAD protocol over a couple weeks – if you have wireshark (for USB sniffing) and a program that works with it. it could be pretty simple, but there’s also a lot of potential for complications depending on how unfriendly the developers were.
It basically depends on getting a machine into the hands of someone who does this stuff, though, because it would be too difficult to do it without the machine at hand to test. You also have to be willing to potentially break the machine. A theoretical concern as far as I know, my original 20W fibre laser still works fine, but it exists. Safety precautions are also needed, it’s totally possible, to, say, accidentally fire the laser when you only mean to be tracing an outline with the targeting diode laser (something that did happen in the course of reverse engineering the BJJCZ controllers, if I recall correctly.)
If you run Linux, Lightburn is no longer supported on that platform, so if you find newer control boards, it might be they are only supported with Lightburn versions 2.0 and higher.
I didn’t need to load a driver, if you see the device with lsusb, then driver is likely OK. With Linux, most of the drivers are there, but may not be installed.
Also many machines use the Serial interface ( /dev/ttyACMX ), yes in that case the drivers are already there.
but this one doesn’t,
if the reverse engineering shows that it is a “serial” connection (hidden Or undocumented to the Linux kernel) , then we can do an ‘ln -s /dev/THATDEVICE /dev/ttyACMX’ , but as I said , cannot take a risk and do that blindly ‘alone’ .
The only time I’ve had to load drivers in Linux is when I got a strange laser from China and it wouldn’t connect. The driver was with the other uninstalled drivers that came with Ubuntu.
the controllers are the same hardware , “we” could the re-flash our FX2P to make it seen as XYZ machine that the software supports … in that case , there might be one more ‘1 step solution’ , but yes very risky even if on paper it works.
I say that because “Cypress EZ-USB FX2LP” is derived from the SDK directly , thus many fiber laser must be using the same solution and just changing name/ branding them, and why not for the usage of their software only … a very commun practice.
and for the N th time, no , and i have changed the rights , and it confirms, my machine needs a driver or recognized by the software, it is not an access issue.
Just to shine a little light (hopefully) on this matter, you should know that the Cypress FX2P is an FPGA chip, which is a software configurable hardware chip. Essentially, the fact that you are seeing a cypress VID:PID means that the chip isn’t flashed with the FPGA design that turns it into a laser controller yet.
IIRC, one of the meerkittens when working on BJJCZ support, ordered a controller board to test with and got one of these uninitialized boards, and IIRC, discovered that the Windows driver install (?) is somehow responsible for flashing the chip and turning it into a BJJCZ-like controller (?) I’m fuzzy on the details.
If it were me, I would attempt to set the laser up in a Windows environment with the software that came with it (ezcad?) and see if that initializes the board, and gives it a more recognizable VID:PID. If so, it may be that the cypress chip will remember that flashing and then you will be able to use it from within Meerk40t in Linux.
This procedure was used for LB before it supported an XYZ laser
and perso , in the past I had Scanners that needed this trick too ( yes more than 20 years ago)
When I get minimal instructions fire WireShark etc , AND get concentrated enough to open the machine (to take pictures of the mobo etc ) I may checkout these things too.
