Comment and trouble similar as Issue #12 NEJE DK-8-KZ cant transfer data correctly

[Jazzjerry]

Hello Camrein,

I absolutely respect your effort and other peoples same mindmap about making the cheap NEJE laser engravers accessible to the Linux users. This is where this type of diy machines should originate.

So I only use linux, and saw this real cheap machine and had a look to see if I would be able to get it running and found some backwards engineering... some scripts and your perfect effort to actually get this machine running on my mint machine...

So I ordered my NEJE DK-8-KZ build by Trustfer hoping I would be able to get it to burn my idears.

And so far... It has burned the test butterfly that was preinstalled on its eprom many times...

I cant seem to get the data connection needed to actually send a new Image 512x512 px to the eprom.

Your EzGraver 3.2 software recognizes the serial connection of my NEJE DK-8-KZ perfectly.

So I try and connect.

connecting to port ttyUSB0 with protocol version 2 connection established successfully loading image: /#####/####/Downloads/ezgraver source/EzGraver-3.2.0/screenshot.png erasing EEPROM uploading image to EEPROM upload completed

So all seems ok up to this point.

The Engraver wakes up after uploading my image through your Gui or Cli..

It buzzes and relocates after a few seconds.

Then I try and start...

Nothing happens.

Not through the Gui nor Cli..

The up down left right reset start pause etc ... buttons have no effect.

When I press the red button on the machine... I starts printing from its eprom and gues what...

It again prints the preinstalled test butterfly NEJE put on the eprom.

I would love to help us out with pentesting and trying to figure out why I cant communicate with the machine. Maybe the protocol has changed.

I tried V1 and V2 of your protocol options that appear automaticly within EzGraver but untill now no result nor any change.

I truely hope you are still reading this and willing to help the diy people on a china budget out to get this working open source.

Sorry to cause this trouble... but hope it might be simple and just something I have overlooked.

I truly hope I will be able to engrave some nuts and autumn nature with poetry on a small scale this year ;-)

I love your work so far. Looks perfect. Hopefully I can get it to work for me.

[camrein]

Hello

Obviously, this sounds very similar to the situation reported at the end of #12. As I have written there, being able to establish a connection (as well as uploading, sending commands, etc.) does not mean the device connected to is correct. It could be a different device which provides a serial port too. EzGraver does not make any checks to validate this.

Could you please do the following (as written in issue #12):

1. Verify that the displayed device being in the dropdown is indeed the engraver.
2. Try opening EzGraver as root user if you confirmed the first point.
3. Ensure that you have a recent version of your Linux distro.

By now, I cannot tell which packages might be missing as with both distros - Ubuntu and Mint - I have played with, they recognized the device without any further help.

PS: The protocols only influence the movement commands (i.e. up, down, left, and right). Anything else has the exactly the same effect.

Cheers Christoph

[Jazzjerry]

I agree and I tried to go through all the steps.

When the NEJE is not connected I get no ports..

~/Downloads/ezgraver source/EzGraver-3.2.0/EzGraverCli $ ./EzGraverCli a Available Ports:

When I plug in the Usb from my NEJE and run the same command I get:

~/Downloads/ezgraver source/EzGraver-3.2.0/EzGraverCli $ ./EzGraverCli a Available Ports: ttyUSB0

So it discovers the NEJE device at ttyUSB0

So point 1 is verified.

Then Point 2

I already changed the privilidges adding my user to the respective group dialout, but just in case will run as root.

I start EzGraver as root

sudo su [sudo] password for XXX: XXX-XXXXXXXX EzGraverUi # ./EzGraverUi instantiating EzGraver on port "ttyUSB0" with protocol version 2 setting burn time to: < transmitting 1 bytes: "3c" starting engrave process transmitting 1 bytes: "f1" erasing EEPROM transmitting 8 bytes: "fefefefefefefefe" converting image to bitmap uploading image transmitting 32830 bytes in chunks of size 8192 Bytes written: 4160 setting burn time to: < transmitting 1 bytes: "3c" starting engrave process transmitting 1 bytes: "f1"

It seems to recognise the NEJE without any problem.. But again the communication seems to be the trouble...... The only EzGraver button that actualy gives some responce is the upload button.

The NEJE buzzes and does som alignment actions. After that none of the buttons work.

And when I press the red Button on the engraver it again burns the preinstalled test butterfly image NEJE prinstalled on the eprom.

My system is up to date and I also tried installing missing dependencies through https://playground.arduino.cc/Linux/Mint

My system= System: Host:########## Kernel: 4.10.0-33-generic x86_64 (64 bit gcc: 5.4.0) Desktop: Cinnamon 3.4.6 (Gtk 3.18.9-1ubuntu3.3) dm: lightdm Distro: Linux Mint 18.2 Sonya Machine: System: CLEVO (portable) product: M860TU Chassis: No Enclosure type: 9 Mobo: CLEVO model: M860TU Bios: Phoenix v: 1.00.07 date: 09/08/2008 CPU: Dual core Intel Core2 Duo P9500 (-MCP-) cache: 6144 KB flags: (lm nx sse sse2 sse3 sse4_1 ssse3 vmx) bmips: 10107 clock speeds: min/max: 800/2534 MHz 1: 1600 MHz 2: 1600 MHz Graphics: Card: NVIDIA G96M [GeForce 9600M GT] bus-ID: 01:00.0 chip-ID: 10de:0649 Display Server: X.Org 1.18.4 drivers: nvidia (unloaded: fbdev,vesa,nouveau) Resolution: 1680x1050@60.11hz GLX Renderer: GeForce 9600M GT/PCIe/SSE2 GLX Version: 3.3.0 NVIDIA 340.102 Direct Rendering: Yes Audio: Card Intel 82801I (ICH9 Family) HD Audio Controller driver: snd_hda_intel bus-ID: 00:1b.0 chip-ID: 8086:293e Sound: Advanced Linux Sound Architecture v: k4.10.0-33-generic Network: Card-1: Intel Ultimate N WiFi Link 5300 driver: iwlwifi bus-ID: 06:00.0 chip-ID: 8086:4235 IF: wlp6s0 state: up mac: Card-2: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller driver: r8169 v: 2.3LK-NAPI port: 5000 bus-ID: 08:00.0 chip-ID: 10ec:8168 IF: enp8s0 state: down mac: Drives: HDD Total Size: 320.1GB (7.7% used) ID-1: /dev/sda model: FUJITSU_MHZ2320B size: 320.1GB serial: K824T882572C Partition: ID-1: / size: 289G used: 19G (7%) fs: ext4 dev: /dev/dm-1 ID-2: /boot size: 472M used: 343M (77%) fs: ext2 dev: /dev/sda1 ID-3: swap-1 size: 4.29GB used: 0.00GB (0%) fs: swap dev: /dev/dm-2 RAID: System: supported: N/A No RAID devices: /proc/mdstat, md_mod kernel module present Unused Devices: none Sensors: System Temperatures: cpu: 51.8C mobo: N/A gpu: 0.0:50C Fan Speeds (in rpm): cpu: N/A Repos: Active apt sources in file: /etc/apt/sources.list.d/google-chrome.list deb [arch=amd64] http: //dl.google.com/linux/chrome/deb/ stable main Active apt sources in file: /etc/apt/sources.list.d/nilarimogard-webupd8-xenial.list deb http: //ppa.launchpad.net/nilarimogard/webupd8/ubuntu xenial main deb-src http: //ppa.launchpad.net/nilarimogard/webupd8/ubuntu xenial main Active apt sources in file: /etc/apt/sources.list.d/notepadqq-team-notepadqq-xenial.list deb http: //ppa.launchpad.net/notepadqq-team/notepadqq/ubuntu xenial main deb-src http: //ppa.launchpad.net/notepadqq-team/notepadqq/ubuntu xenial main Active apt sources in file: /etc/apt/sources.list.d/official-package-repositories.list deb http: //ftp.nluug.nl/os/Linux/distr/linuxmint/packages sonya main upstream import backport deb http: //nl.archive.ubuntu.com/ubuntu xenial main restricted universe multiverse deb http: //nl.archive.ubuntu.com/ubuntu xenial-updates main restricted universe multiverse deb http: //nl.archive.ubuntu.com/ubuntu xenial-backports main restricted universe multiverse deb http: //security.ubuntu.com/ubuntu/ xenial-security main restricted universe multiverse deb http: //archive.canonical.com/ubuntu/ xenial partner Active apt sources in file: /etc/apt/sources.list.d/spotify.list deb http: //repository.spotify.com stable non-free Active apt sources in file: /etc/apt/sources.list.d/webupd8team-java-xenial.list deb http: //ppa.launchpad.net/webupd8team/java/ubuntu xenial main deb-src http: //ppa.launchpad.net/webupd8team/java/ubuntu xenial main Info: Processes: 218 Uptime: 36 min Memory: 1947.9/3945.2MB Init: systemd v: 229 runlevel: 5 default: 2 Gcc sys: 5.4.0 Client: Unknown python2.7 client inxi: 2.2.35

Thanks for the Help and fast reply. I would love to use your EzGraver software.

Cheers Jerry

P.s.

I also tried a python scrypt by https://github.com/AxelTB/nejePrint with similar results.

The NEJE seems to respond on upload and recenter while buzzing a bit. For the rest it does nothing. As if it has another protocol and does not understand the scripts and data we push to it.

Maybe NEJE udated and changed the protocol? How to find out though? I have a CD with windows software and drivers they suplied me.. But dont own a windows machine. Otherwise I could have tried to wireshark on the serial port to see what gets pushed by their software,,,,,....

What do You think?

xxx-xxxxxx nejePrint-master # sudo ./nejePrint.sh /dev/ttyUSB0 mono.bmp [40] (standard_in) 1: syntax error setting port... speed 57600 baud; line = 0; min = 0; time = 0; -brkint -icrnl -imaxbel -opost -isig -icanon -iexten -echo done Handshake... done Sending done home Burning Time 0x preview All Done

[Jazzjerry]

Browsing the NEJE webpage I found some info on the NEJE DK-8-KZ http://www.trusfer.com/Course_En_NEJE_DK-8-KZ.htm

I found out that the software has been updated since 2017.5.27. Maybe that is what is causing the trouble and different results in getting the hardware to work. The software might heve been forked to work for the old NEJE DK-8-KZ with firmware prior to that date and with the new updated NEJE DK-8-KZ that came out after 2017.5.27.

See the info I quoted from the NEJE website below.

Step 2: Install the driver The following is the windows download resources (it is recommended that you use the computer login URL: trusfer.com to download. drive and software for windows,click me download! # # (the software have updated from 2017.5.27) download and decompress before the installation, first install the driver, then install the software, first connect the machine to the computer and then install): download and decompress, first install the driver, as shown below, after the success of the installation click to confirm bottom, and then close the installation window;

Today I also tried to run the software through WINE. I hate Microsoft, but I am eager to get some experiments going with the laser. So Yes I tried the bad bad way around. Just to see if I would be able to at least test it and maybe have a chance of MiTM the protocol to the usb/serial port. To get some data.

But nope dead end.

Greetz Jerry.

The driver.exe actually will install, the engraving software from NEJE however does not install nor run.

P.s. I have called out to some of my friends to see if I can borrow their Windows machine....

They know however that I am a bit of a Hacker and might not be to enthausiastic about that. But maybe... I might be able to at least test the engraver...

And hopefully they will let me use it for a bit longer and I might be able to actualy backwards engineer the protocol... But I think that when I explain what I want to do they will want to take it home straight away....

Cause.... they know me... ;-)

[Jazzjerry]

I tried out using the NEJE DK-8-KZ today on a borrowed win laptop. And it worked.

So its not a dead on arrival.

It should work with linux or in my case Linux Mint 18.2 Sonya.

Out of options at this moment. Unless I can get tat win laptop for at least a day to try and backward engineer the protocol to see how it communicates and if its any different from what we know.

Cheers Jerry

[camrein]

Hi Jerry

Many thanks for your detailed reports about your investigations. Seeing that the serial port is only displayed if you have the device connected proves that it's the correct serial port. Following your hint that the protocol might have changed, supported by the observation of the updated software, it reasons your observation when uploading an image. As I said, being able to upload an image does not necessarily mean it is correctly transferred. The progress EzGraver is generated without the feedback from the device (i.e., wait ~5sec after issuing the erase EEPROM command, upload the image in chunks and track how fast the serial device can read the data written). The buzzing or these life signs you see when uploading an image might hint that the image contains a symbol combination that might be recognized as a command (or maybe the EEPROM command happened to be the same if the protocol changed).

What I just want to confirm. Did you manage to get your DK-8-KZ working with the help of the original Windows Software by trusfer? If that is the case and the Windows version of EzGraver fails exactly in the same way as the Linux version, it is most-likely reasoned to a protocol change.

Unfortunately, I cannot reverse engineer the protocol without having a device at hand (actually, I didn't do this for the original implementation as well as people were kind enough to share their work). If you provide me the protocol (i.e., the bytes transferred in HEX form) from tracking the serial port communication (or maybe already did the work), I'll happily integrate it into EzGraver. This shouldn't be a big deal as the code base is prepared to add support for additional protocols. I just hope that the image is still a monochrome bitmap or at least in a form that is easily producible.

Cheers Christoph

[Jazzjerry]

I would like to confirm I did get the DK-8-KZ working with the software suplied with the machine. When I get the chance I will try out the windows EzGraver version to see what happens.

Best regards, Jerry

[camrein]

Thanks for the update. If you can confirm that EzGraver is not working on said Windows machine (where the original software is working), then it is most likely due to a protocol change as you initially suggested. If this is the case, I will need the updated protocol. However, quickly browsing through other Github projects does not seem there is any project using a different protocol by now. Thus, someone will hopefully be so kind to provide the updated command codes.

Cheers Christoph

[Kryptortio]

Not sure if this will help but I think I have the same problem, I tried the windows software recommended for the specific printer first and got "NEJE V3.0.exe" in that bundle but it was not able to connect. Then I found the updated one "NEJE V3.5.exe" ("updated from 2017.5.27") and that one seems to work. I tried to sniff some of the traffic if that can be of any help, never done this before so I just used https://freeusbanalyzer.com/

The attached data is

• connect - Starting the software with autoconnect
• burn.5.to.10 - Changing burn time from 5 to 10
• send.HELLO - Send the text "HELLO" as image to be printed
• print.HELLO - Start printing of "HELLO"

usb data dump.zip

[camrein]

Thanks a lot for providing this information. I think that's a step in the right direction. Unfortunately, the data you provided only shows the number of bytes written/received. I suppose the data was gathered from a kind of communication overview/summary or something like that. Judging from the application screenshots, I believe it's an extract from the "Sessions" window. Nevertheless, other screenshots, like this one appear to contain the desired data. What I need is the payload of the packets (aka the written and received bytes). If you can somehow provide me the information shown in the screenshot I referred, I think that I can integrate the new protocol into EzGraver.

To avoid unnecessary work (e.g., exporting the wrong data or communication issues), I think the best is simply providing the data used for moving the engraving head (up, down, left, and right). I'll integrate these commands and provide a test binary to see if the commands work as expected. If everything goes well, I'd be grateful if you'd share all the remaining commands afterward.

Regards Christoph

[Kryptortio]

I'm may have exported the "basic" view for some of the html files (print & burn, I can remake them later if needed, I think the other two has the data included). I ran Up-Left-Down-Right and got this:

000000: PnP Event: Device Connected (UP), 2017-10-03 18:47:55,4985879 (1. Device: USB-SERIAL CH340 (COM7)) The USB device has just been connected to the system.

000001: Bulk or Interrupt Transfer (DOWN), 2017-10-03 18:48:05,1136409 +9,6150469 (1. Device: USB-SERIAL CH340 (COM7))

Pipe Handle: 0xf7faf0e0 (Endpoint Address: 0x2) Send 0x4 bytes to the device

FF 03 01 00 ÿ...

000003: Bulk or Interrupt Transfer (DOWN), 2017-10-03 18:48:19,4052755 +14,2915974 (1. Device: USB-SERIAL CH340 (COM7)) Pipe Handle: 0xf7faf0e0 (Endpoint Address: 0x2) Send 0x4 bytes to the device

FF 03 03 00 ÿ...

000005: Bulk or Interrupt Transfer (DOWN), 2017-10-03 18:48:21,2712235 +1,8659186 (1. Device: USB-SERIAL CH340 (COM7)) Pipe Handle: 0xf7faf0e0 (Endpoint Address: 0x2) Send 0x4 bytes to the device

FF 03 02 00 ÿ...

000007: Bulk or Interrupt Transfer (DOWN), 2017-10-03 18:48:22,3443130 +1,0730521 (1. Device: USB-SERIAL CH340 (COM7)) Pipe Handle: 0xf7faf0e0 (Endpoint Address: 0x2) Send 0x4 bytes to the device

FF 03 04 00 ÿ...

[camrein]

Thanks a lot. I have integrated the codes you have provided me in the first commit to the branch protocol_v3. Please give the movement commands in the new protocol v3 (see the updated dropdown options) available in EzGraver_with_v3_movement.zip a try and update me about the results (i.e., did the head move like it does when clicking the buttons in the original software). If everything works, please provide me with the payloads for the remaining commands:

• Home
• Center
• Preview
• Start
• Pause
• Reset
• Set burn time (e.g., three different settings would be probably helpful, maybe something like min/max and some between)
• Upload (this one might be across multiple outputs. Thus it might be a good idea starting a new session for this one to have the data isolated) Best is probably if you attach the uploaded image as well.

Regards Christoph

Update: I see - as you mentioned - that the other two (upload and connect) traces contain the desired data in an easily readable format (excellent). Bad luck that I happened to check exactly the two files that contained no data.

[Kryptortio]

Excellent! That seems to work just just fine. Here is the commands I see in the program.

"Any position locate"" Move to(224,264):

039911: Bulk or Interrupt Transfer (DOWN), 2017-10-03 19:38:18,2687278 +37,0129267 (1. Device: USB-SERIAL CH340 (COM7)) Pipe Handle: 0xf7faf0e0 (Endpoint Address: 0x2) Send 0x8 bytes to the device

FF 0A 02 18 FF 0B 02 40 ÿ...ÿ..@

Center Locate:

039913: Bulk or Interrupt Transfer (DOWN), 2017-10-03 19:40:34,2853671 +136,0165958 (1. Device: USB-SERIAL CH340 (COM7)) Pipe Handle: 0xf7faf0e0 (Endpoint Address: 0x2) Send 0x4 bytes to the device

FF 02 01 00 ÿ...

Rectangle locate (is this preview?):

039919: Bulk or Interrupt Transfer (DOWN), 2017-10-03 19:41:52,3733140 +7,6532542 (1. Device: USB-SERIAL CH340 (COM7)) Pipe Handle: 0xf7faf0e0 (Endpoint Address: 0x2) Send 0x4 bytes to the device

FF 02 02 00 ÿ...

Reboot:

039921: Bulk or Interrupt Transfer (DOWN), 2017-10-03 19:42:05,1700762 +12,7967332 (1. Device: USB-SERIAL CH340 (COM7)) Pipe Handle: 0xf7faf0e0 (Endpoint Address: 0x2) Send 0x4 bytes to the device

FF 04 01 00 ÿ...

Burn time 10->20

039997: Bulk or Interrupt Transfer (DOWN), 2017-10-03 19:47:14,4256223 +21,2251198 (1. Device: USB-SERIAL CH340 (COM7)) Pipe Handle: 0xf7faf0e0 (Endpoint Address: 0x2) Send 0x4 bytes to the device

FF 05 14 00 ÿ...

039999: Bulk or Interrupt Transfer (UP), 2017-10-03 19:47:14,5875155 +0,1618684. (1. Device: USB-SERIAL CH340 (COM7)) Status: 0x00000000 Pipe Handle: 0xf3563d20 (Endpoint Address: 0x82) Get 0x4 bytes from the device

FF 0A 00 14 ÿ...

Pause:

040209: Bulk or Interrupt Transfer (DOWN), 2017-10-03 19:57:57,2266719 +33,4022623 (1. Device: USB-SERIAL CH340 (COM7)) Pipe Handle: 0xf7faf0e0 (Endpoint Address: 0x2) Send 0x4 bytes to the device

FF 01 02 00 ÿ...

File with a dot, sending dot and start with dot dot.zip

[camrein]

Thanks a lot for your effort, glad it worked. So far, I have implemented all commands except for any position locate, home, and upload. I suppose there is no longer a "Home" button or similar in the actual software (perhaps replaced by any position locate? or simply no real use case). I need to review the upload data you have provided later in order to add this last missing feature.

In case you want to play around with the current state (if you do, please inform me if you notice any malfunction, maybe I missed a byte even after double-checking them): EzGraver_protocol_v3_extended.zip

[tinyisland]

Hi, my neje is new and works on windows with the 3.5 software. so it uses the V3-Protocol... But i like Linux, so i played around with ezgraver to make it work with this V3-Protocol

What I found out: Command for erase is: void EzGraverV3::erase() { qDebug() << "erasing EEPROM"; _transmit(QByteArray::fromRawData("\xFF\x06\x01\x00", 4)); }

After that command the engraver responds with: "ff050100"

Then i reduced the EraseTimeMs from 6000 to 50, it seems that the neje waits for data after erase only a short time...

to upload the data i disabled the "image.invertPixels()". also upload should start at byte 62 to cut off the BMP-Header ( "for(int i{62}; i < data.size(); i += chunkSize)")

After the upload the engraver responds with: "ff0b0000"

Best Regards, Richard

[camrein]

Hi Richard

Thanks a lot for your contribution. This was the last tiny bit to make EzGraver fully compatible with the latest protocol version. I already thought about the possibility that they simply stripped the bitmap header, but the number of bytes still didn't match with the one provided by maturz (maybe the software stripped something, or I simply misread/calculated the data).

There are two things that come to mind when seeing your changes:

• You dramatically reduced the erase time. It might be no longer an erase instructions but simply an instruction telling the device that you're uploading an image (simply overwriting the old image). But setting it to 0 might be a problem, depending on how it works (e.g., the signal you're receiving is some kind of "ready" signal). But this just needs testing. However, 50 ms doesn't hurt anyways.
• The 'invertPixels()' instruction was something I had to add earlier as I suppose the BMP header contains an information telling how to interpret the values (i.e., 0 for black and 1 for white, and vice-versa). As I have noticed that other implementations (including a .NET based I made earlier) we're sending the pixels exactly in an opposite format. Without analyzing the BMP format too much, I'm pretty sure it is stated somewhere in the header (probably the DIB header as it seems to be responsible for the pixel format).

I will integrate the final adaptions as soon as possible.

Thanks again, as well as thanks to all others who contributed to making this extension possible Christoph

[camrein]

So I've integrated the changes with the commit 772b514. I had to do a few more adjustments because of the need to reduce the timeout after "erasing". So this version should have all the mandatory features, but I suppose it lacks the recently integrated progress.

I might do a pre-release of this version if this version works as expected (everything except the progress updates). EzGraver_protocol_v3_with_upload.zip

[simonsh]

Thank you for all your work on this. I built protocol_v3 but on launch from the image it says it is not compatible. Does it support Sierra v10.12.6?

[camrein]

I don't think that any changes could have broken OSX support (or Sierra in particular). Of course, I can't be sure as I don't test the OSX builds myself but there are indeed people using the OSX builds. However, there were some issues with the travis-builds some time ago.

To make sure, the best would be downloading one of the older releases. Of course, they do not have v3 support yet, but if you manage to launch EzGraver with these pre-fabricated builds, there is probably an issue with your build.

If you succeed with the execution, you may want to consult the discussion in issue #22. However, the current build that appears to be working does the same as stated in the readme so it might not lead to the desired result.

Nevertheless, if you're patient (and the older builds are working for you): I'm currently preparing a pre-release of the version that includes protocol v3. Unfortunately, the OSX builds of travis are exceptionally slow.

[simonsh]

Thanks for the reply. Your EzGraver_osx.dmg v3.2.0 launches OK but I have a newer engraver, so I suspect it is the protocol. When I try to build from source I get the error no file at "/usr/lib/libEzGraverCore.1.dylib" running macdeployqt EzGraverUi/EzGraverUi.app -dmg that may be the cause but I don't know how to fix the path. If you could supply an image of a protocol_v3 when you have time, that would be great.

[camrein]

I was expecting that it's something like that. Launch errors are not related to the protocol. My guess is, that when generating the dmg the *.dylib file is not found.

The easiest way would be running the make install command after building but prior generating the dmg:

make
make install
macdeployqt EzGraverUi/EzGraverUi.app -dmg

This way the macdeployqt command will find the binaries itself. A more troublesome way is placing the *.dylib file in the correct location as stated in the readme:

make
mkdir EzGraverUi/EzGraverUi.app/Contents/Frameworks/
cp EzGraverCore/libEzGraverCore.1.dylib EzGraverUi/EzGraverUi.app/Contents/Frameworks/libEzGraverCore.1.dylib
macdeployqt EzGraverUi/EzGraverUi.app -dmg

[camrein]

I have released the current development state under the release v4.0.0-beta. Please leave any feedback if you experience any troubles. Although, positive feedbacks are welcomed as well to confirm that everything's working as expected.

[simonsh]

This is great, thanks for your continued efforts. Providing the OSX image saves me a lot of time and hassle. I am burning a test image with v4.0.0 set to v3 protocol at the moment and will report back later.

[simonsh]

v4.0.0-beta test with v3 protocol

I attach the uploaded image and part of the burn, which was stopped early. I am not sure the EEPROM is being erased (which I also tried manually in hex with CoolTerm). I cannot get back to the factory test image.

I am going to find a PC to check that my engraver is working properly, it could be a dud. I will let you know.

[camrein]

It appears to me that image is inverted. My assumptions:

• The image isn't stretched (i.e., you uploaded it in the original size), thus there is a large white space prior the image starts (or a black when engraving it).
• The engraving process was probably canceled before the actual parts of the image.

So, to avoid some unnecessary hassle, you could try these things, to ensure that the upload works as expected (besides the inverted color of course):

• Stretch the image to the full size. That way, the engraver should leave the spots of the image free (quicker noticeable than waiting until the engraver is in the middle of the image).
• Alternatively, simply invert the image color

Hopefully, that does the trick for you for now. Moreover, it helps to confirm that the protocol implementation is correct.

[simonsh]

Yeah, I thought that too, so the dog image was stretched and I am burning a black and white chessboard that fills the window, but with the same result, so far. During the upload, the blue LED flashes and there are no noises until the led stops when it goes through a kind of reset motion.

I'll run the chessboard burn until it finishes this time.

I can send commands through a terminal emulator and happy to do more debugging tests for you.

[simonsh]

Chessboard had the same issue. I installed Windows 10 in a VM (mapping the Windows serial port to the Mac USB serial bridge) and the latest NEJE software. That worked fine. Engraver is not a dud.

I might be able to post a dump the protocol from a typical session (especially the image upload,) if that would help.

[tinyisland]

First I want to say thank you very much for that project! just tested the new version with the new (V3) Neje on my linux-machine. the upload did not work properly, the 50 ms delay were to short, 500 ms worked now (and to see the progress i set EraseProgressDelay from 500 to 5). but for me it seems there is a confirmation message when eeprom is erased

erasing EEPROM transmitting 4 bytes: "ff060100" received 4 bytes: "ff050100"

after having received the "ff050100" upload started correct. so i think we should wait for that answer! and after upload we could wait for "ff0b0000"...

also the pixel-information for the progress changed a little bit : \FF\03....\FF\04....

if((data.size() == 8) && (data[0] == (char)0xFF) && (data[4] == (char)0xFF)) { int x{data[2]*100 + data[3]}; int y{data[6]*100 + data[7]}; _ui->image->setPixelEngraved(QPoint{x, y}); } the format to set the position seems to be similar: \FF\0a....\FF\0b....

best regards, Richard

[camrein]

@tinyisland / Richard: Thank you as well for your effort in testing and supplying your observations and ideas for code improvements. That's certainly helpful, and I appreciate that. I hope you're not too lost in the code. Unfortunately, the quality degraded as I have initially started with the only intention to have a quick replacement for the original software and didn't expect to add so many features (especially the UI part suffered from the vast number of new features). I suppose with your changes the uploaded image is engraved as expected. Thus I've quickly included your suggestions. I have left the part with waiting for the answer (which is, of course, the best way to handle this) by now because I didn't want to rework too much as this requires more time. However, my goal is to have a working beta as soon as possible.

@simonsh: Thanks a lot for your quick updates and active testing. Good to know your device is working correctly. This confirms that there is still an issue with the current implementation and is hopefully fixed with the latest additions by Richard. I hope you don't mind quickly testing the attached windows build on your VM (because I can't build OSX binaries locally, I have to do a release). If this version is working as expected, I'll quickly release the updated version.

EzGraver_protocol_v3_adjusted_erase_time.zip

[simonsh]

No problem, I will have a look at the Windows build when I get some time.

[Jazzjerry]

Wauw... Have been away for few weeks and what an effort has been put in to get things working on V3 of the protocol.

Thank you all working on this.

I tried the new version with protocol v3 and it does some more stuff than usual correct. The up, down, left, right, buttons now work for me! The center does not but thats not important.

I also tried uploading an image. And it seems to work. When I press start though.... It does not do anithing, or it starts to engrave a line. over and over. deeper and deeper. ;-)

I tried to find out if I would be able to simply contact www.trustfer.com and simply ask them for the protocol and changes.

But that is simply not that easy. No visual way of communicating through Email.

The only thing I was able to find is:

Manufacturer: Shenzhen ZhiXinJie Technology Co., Ltd All rights reserved 2013-2017 Tel:86-186 0302 1351 QQ：867819731 CE / FDA

So there you go A phone number... But hey, I dont dare and call them. Dont realy know how to explain what we need.

Then I did some more online resaearch and found this Email adress:

WHOIS Lookup Domain Name: TRUSFER.COM Email: wuhonghe126@126.com

So maybe someone could put in the effort to ask them for what we need? I dont realy now wat we need, but Hey I hope this can Help.

Greetz Jerry.

P.s. I also tried the 4.0 Beta... No luck.

As soon as I try and upload an image the laser starts behaving erational as if it sees the img as coordinates and burning instructions.

[lmftiv]

WARNING !!!!!!!!!!!!!!!!!!!!!!

EzGraver_protocol_v3_adjusted_erase_time.zip This version bricked my DK-8-FKZ !!

Even the original NEJE_v3.5 software can't find the printer anymore.

This happened after image download that got stuck on 100%.

I'll report later if I get the machine working again... :(

ps. Phew... After taking the machine apart I disconnected the battery and repeatedly pressed the reset button on the mainboard the machine came back to life!

[camrein]

Thanks for all your feedback and efforts to finalize the support for the latest devices. Unfortunately, the image upload seems to be quite different to the earlier versions (or it might even differ between the generation). It's rather difficult to add support for a device you do not personally own and therefore cannot test it yourself. If anyone would be able to provide a working configuration (+ which device he's using), that might help others and maybe me as well. Otherwise, we'd probably have to wait until someone publishes the fully reverse-engineered protocol. One last thing I think that could be the troublemaker is the hardcoded time between erasing and uploading the image to the EEPROM. As earlier suggested, it would be better to work with the callback codes, and I think this will be the next try (if I find a way without having to change large parts of the code).

@lmftiv: I'm sorry to hear about your trouble (and I appreciate your effort in sharing your experience). Upon first reading your report it sounded to me like an issue that I had earlier with my machine. More precisely, if the timing between erasing and uploading was too short, my device felt stuck as well. I suppose this is due to the machine treating each incoming byte as a part of the image until the expected length was received (sending the image data too early leads to the situation that the first parts are ignored). I only managed to get the machine back working when fully disconnecting it from any power source. I'm glad that you managed to get your machine back working as I wouldn't have thought about the possibility that the newer devices might have a battery included. But as I have written, this sounds pretty much the same as I have experienced and that there is more or less an issue with the timing between erasing and uploading the image. As written in the first paragraph, I most likely have to handle the callback by the device to get the upload time right.

[lmftiv]

If there is anything I can do to help please let me know. I have the DK-8-FKZ version.

[camrein]

If you manage to find another open-source project supporting your device, that would be the jackpot. :) Otherwise, I'd be grateful if you give an updated version another try (if you're brave enought ;)). I think I will try handling the response code of the engraver next as the implementation is probably not fully defective as @tinyisland has success with the upload functionality by manually adjusting the time. But I guess it just happens to match the transfer times for his device/computer (a slower controller might need a larger delay whereas a faster would need a smaller).

[lmftiv]

https://sourceforge.net/projects/neje-laser-engraver-extended/files/

Beware it is infected with coinhive and doesn't work after antivirus software stopped it... Maybe something interesting in the sourcecode...

[camrein]

Thanks for the link. I have seen these sources earlier but just double-checked to make sure. It appears to me that (at least the sourcecode) is targetted for earlier devices (aka not protocol v3 in EzGraver terms). However, is the provided binary working for you? If that is the case, I could try de-compiling it

[Jazzjerry]

OK. I have an ancient win laptop I got for free from a friend of mine..

I used to run winXP according to the microsoft sticker, And I installed win7.

And yes! it runs... SLOWLY.... ;-)

I installed microsoft.net I installed the CH340 usb-serial driver I installed the original windows NEJE 3.5 software

I tested the laser and it works.

Now to sniff Data..

I Installed usbpcacp... But have not been able to use it yet. need to read up some more!

Working on it!

[Jazzjerry]

Seems usbpcap is just the driver.

Also seems Wireshark is the gui to use. So installing wireshark at the moment.

[Jazzjerry]

Seems usbpcap and usb sniffing does not work through wireshark on windows... only on linux sigh.....

[philippzuber]

how about this tool?

http://desowin.org/usbpcap/tour.html

Cheers Philipp

2017-11-26 17:20 GMT+01:00 Jazzjerry notifications@github.com:

Seems usbpcap and usb sniffing does not work through wireshark on windows... only on linux sigh.....

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/camrein/EzGraver/issues/34#issuecomment-347020010, or mute the thread https://github.com/notifications/unsubscribe-auth/AMTFTqq3ycLKeQHgU5r_OilHvWid5zsEks5s6Y-5gaJpZM4PiAIx .

[lmftiv]

I tried the latest code version and it behaved little different from last time.

Now the image transfer started, the laser resetted itself and draw a square around the image, started the image transfer again and then stopped. Good news is that the laser didn't brick this time. Bad news is that the image printed was all black. So the transfer didn't succeed.

I tried also the multi layer image burn and this time the laser bricked at the first image transfer. I got the machine back again with the reset button inside.

So we have some progress... :)

[camrein]

@lmftiv Thanks a lot for your update. @tinyisland was so kind sending a pull request which I have merged into the protocol_v3_fixes branch right now. Could you please give it another try?

Edit: The mentioned fix will probably not work yet as it appears to be incomplete unless I have missed something.

[lmftiv]

Still no success... Randomly bricks at image transfer and only prints all black image.

[camrein]

I have committed a now ultra-experimental pre-alpha (and whatever) version of an implementation that waits for a specific response when uploading an image to the device. As my version description implies, it's just stitching together to quickly have a version that hopefully works as I expect it to work. You should notice additional print-outs to the text box on the right when uploading an image. However, if it's not receiving the answer I'm currently expecting, you'll immediately have the "brick" you're experiencing by now.

If you test it, please share the text output you're receiving. It should be something like this:

erasing EEPROM
erase timeout reached for protocol v3 without receiving response from device
received answer from engraver length (...): ...
uploading image to EEPROM

The last line will only appear if the "answer" is the one that is expected.

[lmftiv]

connecting to port COM4 with protocol version 3 connection established successfully resetting engraver loading image: C:/Users/Omistaja/Downloads/Polttokuvat/67_0.jpg erasing EEPROM received answer from engraver length (4): ff050100 uploading image to EEPROM erase timeout reached for protocol v3 without receiving response from device upload completed received answer from engraver length (4): ff0b0000 uploading image to EEPROM upload completed <--- engraver draws box around the image starting engrave process with burn time 10 <--- Nothing happens after this resetting engraver resetting engraver resetting engraver resetting engraver

[firstel]

same for me. i wonder if there is a 3.1 protocol or something?

[cybervegan]

Hi all, I've just got hold of one of these and stumbled across this thread whilst looking for a FOSS solution that lets you engrave your own pictures. EzGraver looks really good, but obviously doesn't handle the DK-8-FKZ yet. I'd like to lend a hand getting this working, and to that end, I've done some packet traces using Wireshark, and I've discovered a few things.

1. The maximum image dimensions have changed: the User's Manual specifies 490x490 dots rather than 512x512.

2. It looks like the image size transmitted is now variable - if you just print some small text (I tried dots and vertical bars) the official windows software only transmits a very small amount of data (in my case, 88 bytes), which leads me to believe that there must be some kind of dimension header. However this is not transmitted as part of the image data, as confirmed by the packet trace. I've confirmed, with a bit of Python, that the data being transmitted matches the image I captured being printed.

3. It seems that the comms do in fact differ from the V3 protocol - the sequences I have seen do not match what EzGraver is trying to send. The windows software also chunks that image in 4k segments, with a "runt" packet (not truncated) at the end, containing any overspill.

If you want the packet traces, please let me know and I'll upload them for you.

[cybervegan]

Ok, after doing further research, it seems that the manual lies: the maximum res DOES NOT seem to be 490x490, but it DOES seem to be variable. Etching a smaller image results in fewer data packets, with a smaller total size, being sent to the etcher, and a larger image, results in more packets, with a larger total size.

I think it must be sending a message which describes the dimensions of the image, but I can't work out (so far) how it's encoded. The first thing that the official software sends is the following three message packets (xx marks variable octets - the others seem to be constant across jobs):

URB_BULK out, payload: ff 6e 01 xx xx xx xx URB_BULK out, payload: ff 6e 02 xx xx xx xx URB_BULK out, payload: ff 0e 00 01

Then there's a bit of USB protocol-level chit-chat (not familiar with this, and haven't yet looked into it) before it eventually sends what looks a bit like the "old" EEPROM Erase message, but with a "01" as the last octet, instead of "00":

URB_BULK out, payload: ff 06 01 01

The engraver echoes this back with the second octet set to "05":

URB_BULK in, payload: ff 05 01 01

Then the image data is sent, in chunks of 4096 bytes, with the last, smaller packet, taking up the overspill:

URB_BULK out, payload 4096 bytes URB_BULK out, payload 4096 bytes ... URB_BULK out, payload $overspill bytes

The engraver then immediately begins the job, and spews copious packets, which I presume are the progress data.

I've played around with the data using a little python I wrote to display the binary data as an ascii rendered "image", and I can identify the dimensions from this: for example, the last image I printed worked out at 496x489. 30318 bytes were transferred, in 7 packets of 4096 octets, followed by one 1646 octet packet. 496/8 = 62 bytes per row; 30318/62 = 489 rows. The header packets for this were:

URB_BULK out, payload: ff 6e 01 00 00 00 00 URB_BULK out, payload: ff 6e 02 04 60 04 59 URB_BULK out, payload: ff 0e 00 01

So far I haven't been able to work out how the dimensions are encoded in this. It doesn't seem that any of the raw values (62 bytes or 496 bits per row, for example) are encoded anywhere in this header "in the clear". I suspect it's being obfuscated or maybe even encrypted somehow.

Some of other examples (with less certainty about the dimensions):

Data bytes were 26352 bytes/octets. Image as measured with my callipers was about 488 x 432. URB_BULK out, payload: ff 6e 01 00 03 00 1d URB_BULK out, payload: ff 6e 02 04 58 04 20 URB_BULK out, payload: ff 0e 00 01

Another very small image was 88 octets, in one packet: URB_BULK out, payload: ff 6e 01 02 2b 02 01 URB_BULK out, payload: ff 6e 02 00 08 00 58 URB_BULK out, payload: ff 0e 00 01

[cybervegan]

Oh, I forgot to mention that the manual gives the point distance as 0.075mm, and the dimensions as 36.75x36.75mm. 36.75/0.075=490. But 490/8 (to give octets per row)=61.25, which you have to round up to 62 octets max per row.

[onebeartoe]

cybervegan and others here, thanks for putting this information up. I am currently looking to use the progress feedback that the Neje machines give off while engraving.

With the different protocols (and code around them), I think it would be a good idea to have a profile to select for each Neje machine.

I am working on a Web app that is a wrapper for the CLI verison of the code.

http://electronics.onebeartoe.org/3d-realization/laser/engraver/neje/engrave/

I don't mean to hijack this thread, but is there a breakdown of which EzGraver protocols work with which Neje machines?