Comment and trouble similar as Issue #12 NEJE DK-8-KZ cant transfer data correctly #34
Comments
|
Hello Obviously, this sounds very similar to the situation reported at the end of #12. Could you please do the following (as written in issue #12):
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 |
|
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 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 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 It seems to recognise the NEJE without any problem.. The NEJE buzzes and does som alignment actions. 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 My system= Thanks for the Help and fast reply. Cheers 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. Maybe NEJE udated and changed the protocol? What do You think? xxx-xxxxxx nejePrint-master # sudo ./nejePrint.sh /dev/ttyUSB0 mono.bmp [40] |
|
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. See the info I quoted from the NEJE website below.
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 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... ;-) |
|
I tried out using the NEJE DK-8-KZ today on a borrowed win laptop. 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 |
|
Hi Jerry Many thanks for your detailed reports about your investigations. 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 |
|
I would like to confirm I did get the DK-8-KZ working with the software suplied with the machine. Best regards, |
|
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 |
|
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
|
|
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. 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 |
|
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:
|
|
Thanks a lot. I have integrated the codes you have provided me in the first commit to the branch protocol_v3.
Regards Update: |
|
Excellent! That seems to work just just fine. Here is the commands I see in the program. "Any position locate"" Move to(224,264):
Center Locate:
Rectangle locate (is this preview?):
Reboot:
Burn time 10->20
Pause:
File with a dot, sending dot and start with dot |
|
Thanks a lot for your effort, glad it worked. So far, I have implemented all commands except for any position locate, home, and upload. 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): |
|
Hi, my neje is new and works on windows with the 3.5 software. so it uses the V3-Protocol... What I found out: 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, |
|
Hi Richard Thanks a lot for your contribution. This was the last tiny bit to make EzGraver fully compatible with the latest protocol version. There are two things that come to mind when seeing your changes:
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 |
|
So I've integrated the changes with the commit 772b514. I might do a pre-release of this version if this version works as expected (everything except the progress updates). |
|
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? |
|
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. 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. |
|
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. |
|
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
make install
macdeployqt EzGraverUi/EzGraverUi.app -dmgThis way the |
|
I have released the current development state under the release v4.0.0-beta. |
|
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. |
|
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.
|
|
It appears to me that image is inverted. My assumptions:
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):
Hopefully, that does the trick for you for now. Moreover, it helps to confirm that the protocol implementation is correct. |
|
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! |
|
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. @lmftiv: |
|
If there is anything I can do to help please let me know. I have the DK-8-FKZ version. |
|
If you manage to find another open-source project supporting your device, that would be the jackpot. :) |
|
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... |
|
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). |
|
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 tested the laser and it works. Now to sniff Data.. I Installed usbpcacp... Working on it! |
|
Seems usbpcap is just the driver. Also seems Wireshark is the gui to use. |
|
Seems usbpcap and usb sniffing does not work through wireshark on windows... only on linux sigh..... |
|
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
<#34 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AMTFTqq3ycLKeQHgU5r_OilHvWid5zsEks5s6Y-5gaJpZM4PiAIx>
.
|
|
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... :) |
|
@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. |
|
Still no success... Randomly bricks at image transfer and only prints all black image. |
|
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. If you test it, please share the text output you're receiving. It should be something like this: The last line will only appear if the "answer" is the one that is expected. |
|
connecting to port COM4 with protocol version 3 |
|
same for me. i wonder if there is a 3.1 protocol or something? |
|
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.
If you want the packet traces, please let me know and I'll upload them for you. |
|
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 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 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 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. Another very small image was 88 octets, in one packet: |
|
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. |
|
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? |
|
When I looked at EzGraverCLI, I couldn't see any way to select/use
different protocols.
I don't know if there's a map of protocols to models, sorry.
…On Wed, Sep 5, 2018 at 4:28 AM Roberto Marquez ***@***.***> wrote:
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?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#34 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AHTZwwzA50ksZGq1qRoJrdhpTbmDN221ks5uX0T4gaJpZM4PiAIx>
.
|
|
Yeah, same here cybervegan. I guess I more meant that it would be useful to be able to select a target protocol and/or model. |
|
Hi all, I was able to get my hands on a Neje DK-8-KZ with the new protocol. Other files and test-image are located here (forked from AxelTB/nejePrint ): The image size conversion is strange: Hope that helps |
|
That's great news. Thanks for putting in the work. I'll see if I can brush off the NEJE and give it a spin later today. (BTW, can't seem to find my old login details, so using these instead of @cybervegan). |
|
Hi all, I was able to get my hands on a Neje DK-8-KZ with the new protocol. Other files and test-image are located here (forked from AxelTB/nejePrint ): The image size conversion is strange: Hope that helps |
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.
The text was updated successfully, but these errors were encountered: