Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

I have a Dremel 3D40 and I'd like to contribute #60

Open
number-g opened this issue Oct 28, 2020 · 49 comments
Open

I have a Dremel 3D40 and I'd like to contribute #60

number-g opened this issue Oct 28, 2020 · 49 comments
Labels
Dremel 3D40

Comments

@number-g
Copy link

Hi,

I have a Dremel 3D40 and I'd like to contribute to getting this machine to work with this plugin.

I obtained the source code for Dremel's version of Cura from Dremel/Bosch europe and put it up here:

https://gitlab.com/number-g/dremel-digilab-3d-slicer-1.2.3

Not sure how useful that is or where to look for useful things but there it is.

There was also another folder in the archive called "curaengine" which also seems to be a git repository but I am not really familiar with git so I couldn't figure out how to upload it to gitlab ... I think it was still somehow configured to use their in-house git instance. I've uploaded it here (but the link will expire in 30 days):

https://easyupload.io/jxd6ng

Please let me know if this is of any use and how I can help. I have plenty of time.

Cheers
@Mrnt
Copy link
Owner

Mrnt commented Oct 28, 2020

Thanks for sharing that - I will take a look when I get a chance.

Any help is welcome, especially around testing and debugging issues! What set up are you using - OctoPrint/Dremel Digilab on Windows/Mac/etc?

@number-g
Copy link
Author

number-g commented Oct 28, 2020 via email

@Mrnt
Copy link
Owner

Mrnt commented Oct 28, 2020

It's not cooperating so far

I'm assuming that you installed this plugin already - what exactly is happening? Are you able to connect to the printer using OctoPrint? If you have not already done so - turn on debugging for the plugin as it will generate a lot of messages that should help diagnose most issues.

@number-g
Copy link
Author

number-g commented Oct 28, 2020 via email

@number-g
Copy link
Author

number-g commented Oct 28, 2020 via email

@number-g
Copy link
Author

number-g commented Oct 28, 2020 via email

@Mrnt
Copy link
Owner

Mrnt commented Oct 28, 2020

I just made it separate section for it in the README

@number-g
Copy link
Author

Here's a fresh log (deleted all the old ones, restarted printer, then restarted octopi and attempted a print):
octoprint.log

@Mrnt
Copy link
Owner

Mrnt commented Oct 28, 2020

When you say it doesn't work, can you describe what is happening?

I see that the status messages sent by the printer are different from the other printers, so that is potentially an issue. However, it does look like you are able to connect to the printer and start a print - then you cancelled the print?

@number-g
Copy link
Author

number-g commented Oct 28, 2020 via email

@number-g
Copy link
Author

number-g commented Oct 28, 2020 via email

@Mrnt
Copy link
Owner

Mrnt commented Oct 28, 2020

When I hit print, the z axis motor activates and appears to be trying to pull the bed downwards and since the bed is already at the lowest point, it just makes a horrible noise and worries me that I might strain the motor

Ah ok, I'll take another look at the log and see why that might happen - sounds as though it did not finish homing (G28). You can test homing by issuing the G28 command directly in the OctoPrint terminal tab.

Are you using a file that was created using Digilab or some other slicer?

@number-g
Copy link
Author

number-g commented Oct 28, 2020 via email

@Mrnt
Copy link
Owner

Mrnt commented Oct 28, 2020

if you try:
G28 X Y Z
what happens?

@number-g
Copy link
Author

Send: G28 X Y Z
Recv: status: ready
Recv: temperature: 227
Recv: extruder_target_temperature: 225
Recv: platform_temperature: 0
Recv: chamber_temperature: 0
Recv: buildPlate_target_temperature: 0
Recv: error_code: 200
Recv: door_open: 0
Recv: remaining: 0
Recv: totalTime: 0
Recv: firmware_version: v1.0_R03.06.06
Recv: jobstatus:
Recv: progress: 0
Recv: layer: 0
Recv: jobname:
Recv: elaspedtime: 0
Recv: networkBuild: 0
Recv: filament_type: PLA
Recv: usbBuild: 0
Recv: fanSpeed: 0
Recv: message: success
Recv: ok
Recv: CMD G28 Received.
Recv: ok
Recv: status: ready
Recv: temperature: 227
Recv: extruder_target_temperature: 225
Recv: platform_temperature: 0
Recv: chamber_temperature: 0
Recv: buildPlate_target_temperature: 0
Recv: error_code: 200
Recv: door_open: 0
Recv: remaining: 0
Recv: totalTime: 0
Recv: firmware_version: v1.0_R03.06.06
Recv: jobstatus:
Recv: progress: 0
Recv: layer: 0
Recv: jobname:
Recv: elaspedtime: 0
Recv: networkBuild: 0
Recv: filament_type: PLA
Recv: usbBuild: 0
Recv: fanSpeed: 0
Recv: message: success
Recv: ok
Send: M105
Recv: CMD M105 Received.
Recv: T0:226 /225 B:0/0
Recv: ok
Recv: status: ready

@Mrnt
Copy link
Owner

Mrnt commented Oct 28, 2020

Did it move at all?

@number-g
Copy link
Author

Sorry I had to go out for a bit; no nothing at all

@number-g
Copy link
Author

number-g commented Oct 29, 2020 •
edited

If i manually raise the bed to half way then the X axis seems to try to go in a direction that isn't possible.

When the printer is idle, the extruder is on the right of the X axis and it seemed to try to go right

Is there a setting to invert the axes?

I found a setting in Printer Profiles//Axes that says:

"Please define the maximum speed/feedrate of the individual axes and whether their control should be inverted or not. "

I've tried inverting them/not and it doesn't make a discernable difference

@KeltE
Copy link

KeltE commented Oct 29, 2020

Hello. Isn't the USB stick accidentally connected when you connect the Octopi? My Dreamer NX behaves strangely when the SD card is in the printer and I want to print via Octopi. Just remembered reading the post.

@number-g
Copy link
Author

Thanks,

I tried it without the USB stick and it still behaves the same; it seems like at least 1 axis is inverted ... changing that setting in the printer profile though only seems to affect manual control

@Mrnt
Copy link
Owner

Mrnt commented Oct 29, 2020

Typically it is the Z axis that is inverted. But that setting is just for the purposes of the "Control" tab on OctoPrint which uses relative positioning - ie if you press the "up" arrow and it goes down then you need to go into the printer profile and set the Z axis to be inverted. What is happening when you use the controls in the "Control" tab is the printer is being sent Relative (not Absolute) positions - eg move the X axis to the right 10 steps would be G1 X-10. However the slicer typically generates movement instructions that are Absolute, so if the head was currently at a position of X=23 Y15 and it wanted the head to move right by 10 it would send a command G1 X13.
In other words the axes inversion settings typically only affect manual control of the printer.

@Mrnt
Copy link
Owner

Mrnt commented Oct 29, 2020

I am concerned that sending G28 to the printer using the terminal window has no effect. Presumably hitting the 'home' buttons on the "Control" tab also have no effect?

If G28 does not work then you will only be able to print using OctoPrint by uploading files using the "Upload to SD" button.

@number-g
Copy link
Author

number-g commented Oct 29, 2020 via email

@Mrnt
Copy link
Owner

Mrnt commented Oct 30, 2020

Unfortunately the older printers do not provide a list of what is on its SD card, so I stopped sending the request to the printer (I doubt the 3D40 supports it either) so you will not see that information in OctoPrint. It's really rather frustrating it does not work.

I would be interested in seeing a log file of what happens when you upload to the SD card and get the printer is busy message.

@number-g
Copy link
Author

number-g commented Oct 30, 2020 via email

@number-g
Copy link
Author

Log:
octoprint.log
Screenshot:
Screenshot

@Mrnt
Copy link
Owner

Mrnt commented Oct 30, 2020

Ah I see the problem. The status reporting in response to the M119 command is quite different from the other printers I have looked at, so the code is not able to tell what state the printer is in when it connects (printing/idle/etc) so it thinks the printer is not ready for an upload.

@number-g
Copy link
Author

Is there anything I can do to provide more information to go on?

@Mrnt
Copy link
Owner

Mrnt commented Oct 30, 2020

I made a branch with some code to try to accommodate the response from the Dremel. You can test it by loading it into OctoPrint:

  1. Go to Settings > Plugin Manager
  2. Click the Get More button
  3. In the box ... from URL paste the link https://github.com/Mrnt/OctoPrint-FlashForge/archive/Dremel_3D40.zip then click Install
  4. Restart OctoPrint

Try uploading to SD and then put the octoprint.log file in here.

@number-g
Copy link
Author

Thanks! I will try it as soon as the current print is done.

Do I need to disable the original plugin first?

@Mrnt
Copy link
Owner

Mrnt commented Nov 1, 2020

It will just replace the original code since it has the same name. The version number is the same so next time there is a release the plugin should automatically be updated without a problem.

@number-g
Copy link
Author

number-g commented Nov 1, 2020

Thanks,

I haven't had a chance to try it out yet because I've noticed that the prints [via the usb stick not via octoprint or this plugin] that I have been printing which had an M3 aperture (self tapping) no longer hold the screw.

So far as I can understand, I haven't changed any settings so I am worried that the times when I was trying to get this working and the machine was going VRRRRRRRRRRRRRRRRRRRRRRRRRRROOOOOOOUUUUUWWWWWWWWWWWW might have stretched the belts, so until I can figure out how to get the machine back to how it was(or remember a setting that I might have changed), my input is not going to be useful

As soon as I get the printer back to how it was I will get back to you

@Mrnt
Copy link
Owner

Mrnt commented Nov 3, 2020

VRRRRRRRRRRRRRRRRRRRRRRRRRRROOOOOOOUUUUUWWWWWWWWWWWW might have stretched the belts,

Oh that's not good. If you feel the belts do they seem loose? Maybe print a calibration cube or cylindrical column?

@number-g
Copy link
Author

number-g commented Nov 3, 2020

I can only really access the X belt at the moment and it seems fine, I need to take the thing apart to check the others as they are sort of hidden by the case design.

Had to order some long security torx bits so I'm waiting for those before I can have a proper look. Hopefully it's as simple as just the belts ... I do have spare stepper motors around too though.

@number-g
Copy link
Author

number-g commented Nov 3, 2020

Just tried to install your new code ... I forgot that I am still using a weak power supply on the pi so I will have to find a better one as it's refusing to install due to the pi being throttled.

I will try to find a better one today and try again.

I'm sure the printer will be fine once I can get a proper look at the Y and Z belts. I think it's most likely that a screw has rattled loose the more I think about it

@number-g
Copy link
Author

number-g commented Nov 3, 2020 •
edited

Ok, so the new code uploads files created in Dremel Digilab to the SD ok, then it automatically calibrates, heats the nozzle, looks like it's about to start to print but then the print head just moves to the back right of the machine and the interface comes up with the dialogue that it usually comes up with when a print has finished.

I tried uploading some gcode from Cura but it didn't seem to like it

EDIT: Actually it accepted a different file from Cura but did the same as the above.

I noticed though that it did thow an error on the upload, and a connection error on the left:
Untitled

@Mrnt
Copy link
Owner

Mrnt commented Nov 4, 2020

Can you upload a log file - it might give some clues.

Pretty odd that a file created in Digilab would not work if you were able to upload it using OctoPrint and the printer started printing - once the file is uploaded and the print starts, the plugin should not have any effect on the printer unless you hit cancel or pause.

@number-g
Copy link
Author

number-g commented Nov 4, 2020

Sorry, I should have clarified my edit.

Both Digilab and normal Cura seem to successfully home the printer, cause it to auto calibrate, heat the head, then act as if the print has been made after not having printed anything.

I assume that this means that it registers something but the gcode is not being uploaded.

I'll erase the old logs and upload a fresh one

@number-g
Copy link
Author

number-g commented Nov 4, 2020 •
edited

Before it says error starting print there is something that says streaming failed but it disappears before the above.

Just had to type that as it happened otherwise I might omit it due to concentrating on other things

Now the nozzle it heating and its about to move the bed up then end the print without printing

@number-g
Copy link
Author

number-g commented Nov 4, 2020

And now when I try to save the log through the Octoprint UI, Firefox gives me this error:

"/tmp/mozilla_g0/27Vbo+nI.log.part could not be saved, because the source file could not be read.

Try again later, or contact the server administrator."

The Octoprint UI says it's 20kb but Mozilla says it's ~900kb before not allowing me to save it.

Where can I find it on the filesystem?

@number-g
Copy link
Author

number-g commented Nov 4, 2020

octoprint.log

@Mrnt
Copy link
Owner

Mrnt commented Nov 10, 2020

sorry for the delay in getting back to you. It looks like something went wrong at completion of the file upload - though I cannot tell what. It does not respond to the M29 (file transfer complete) command and then does not respond to a subsequent status request which makes me think the printer is stuck in some state - did you notice anything displayed on the printer screen, like "file error".

One thought is the the file name is awfully long: D3_strutcap_revised_for_domekitd92fe1b4477d546eb6804c5a1b71a26f-strutcap-revised.gcode - I would try shortening it down to about 10 characters plus the file extension (.gcode) and see if that helps.

there is not indicatio

@number-g
Copy link
Author

No problem; I'll try with a shorter filename and check the screen

@number-g
Copy link
Author

I used a file called "hub.gcode" this time; same results as before and no error messages on the printer screen.

octoprint.log

@Mrnt
Copy link
Owner

Mrnt commented Nov 12, 2020

Looks like I need to add some code to shorten the name.

@number-g
Copy link
Author

number-g commented Dec 2, 2020

Any progress with this?

@number-g
Copy link
Author

I've resolved the physical issues with the printer; the vibrations had just loosened the nut securing the bed slightly so it only needed tightening.

Did you get anywhere with the code to shorten the name? Or could you direct me where to look?

Thanks

@bvaerewyck
Copy link

I have a Dremel 3D45 but I see that it has been a while since this originally posted. Is there still any interest in the development of this?

@number-g
Copy link
Author

number-g commented Dec 7, 2021 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Dremel 3D40
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@Mrnt @bvaerewyck @number-g @KeltE