Maestro getting started

infamous_panda

Hello all, Got myself a Duet Maestro. I believe I have wired it to my Little Monster properly. Getting started guides seem to be lacking at this point. Is connecting to the board the same process as the current Duets? I have connected it to USB but nothing shows up on the device manager. Any insight?

streamliner

I am new to the Duet world myself, but I do have the Duet 2 Maestro... I just ended up creating an sdcard with my config on it, plugging it in via ethernet, and going from there... i did initially install a driver for the board, but I believe it was not specific to the maestro but rather any duet board. One thing I have seen mentioned is that some wiring has changed, I don't know if this is between the prior duet generation and this one, or between the duet2 eth/wifi and the maestro. Anyways, anything I can do to assist -- let me know, I am quite familiar with the board now. I'm using it to drive a dev model of a mixing head

dc42

We have mostly updated Duet documentation to cover the Duet Maestro. Setting up should be done as for the Duet Ethernet, including installing the same Windows USB device driver. The main area currently missing from the documentation is how to set up the screen layout if you use a 12864 display attached to the Maestro.

Wiring the Maestro is the same as for the other Duets except for the following:

The power in and bed heater connections are made to the 4-way barrier strip instead of terminal blocks.
The Z probe connector has a 5th pin with +5V on it, for powering BLTouch and other Z probes that need +5V.
The extruder heater outputs are available on both the 2-way terminal blocks and on 2-pin Molex connectors. The Molex connectors are suitable for use in 24V systems with extruder heaters rated 40W or less. When using 12V power or higher powered heaters, you should use the terminal blocks because they have a higher rated current.
The Maestro has a smaller and much more limited expansion connector.

infamous_panda

Thanks, I am connected now. Turns out I should not have replaced the configurations files with ones that were created for my machine but for Duet2 Ethernet/Wifi....

Couple things I am seeing.

Comparing my settings to smoothieware and to the Reprap files others have made for this machine. The steps per inch for xyz are 160. However now on the duet Maestro I need to step this back to 80 to get accurate movements. Any insight why? Is the standard duet vs Maestro any different in this regard?

I have a 12864 lcd connector with the rotary control. The stop button resets the machine. The rotary does not seem to do anything at this point. It displays

Tool
Hotend
Bed
Fan

Of these only the Bed temperature is showing accurately. The rest show fine on the web interface.

infamous_panda

Oh additionally, I had issues where I was getting a short error on the drives. This was before even try to move the effector. Just on homing. turns out the homing speed was set very high by reprap configurator, thought this was not a setting that I had access to from that tool.

dc42

I have added the provisional documentation on the Duet 2 Maestro menu system to the wiki at https://duet3d.dozuki.com/Wiki/Edit/Duet_2_Maestro_12864_display_menu_system. However, not all commands are implemented yet, in particular the "files" command isn't in my fork of RRF. M3D has a fork of RRF with a more complete implementation. I plan to merge their changes into my fork at version 2.02.

The steps/mm you need will depend on the belts and pulleys you use, whether you are using 1.8 or 0.9deg motors, and what microstepping you select. 80 steps/mm is correct for 20-tooth GT2 pulleys used with 1.8deg motors and x16 microstepping.

infamous_panda

@dc42 Thanks for this. Sorted out the steps per inch, It was the microstepping setting.

crussty

@dc42 Have you gotten any further on merging/documenting the LCD menu system? Trying to create the simple menu shown at your line above using the example provided, but doesn't look like the 'menu' parameter shown in the example is valid (per the listed parameters above it). I've been trying to find the M3D repo, and found their example of menu files for the SD card on GIT, but can't find their firmware version to test it with.

Many thanks!

dc42

That merge is on my to-do list. I think the M3D version you want is probably https://github.com/PrintM3D/RepRapFirmware/tree/v2-feature/morecomplete12864.

crussty

@dc42 Thank you sir! I spend all night googling for that!

streamliner

Hey @dc42 -- nice to chat with you guys as per usual. I am actually going through and uncovering some of that particular aspect of the 12684 branch from the M3D side now. We have a few things spread out since Matt's departure, and we just found a MAJOR portion of work we had thought was lost. I'll be putting it up on the m3d repo soon.

Thanks,

David Hargrove
PrintM3D

streamliner

I hope you don't mind if bring it up here as well since we it seems to now be the discussion.

@crussty I am going to put up all of my most recent updates, some were comitted some were not. Dealing with the emergency departure of an employee from a few months ago, no biggie

I am actually having a really confusing issue; I am on Win 10 at the moment and today I was trying to recompile The Duet Firmware with the v2_dev_12864 complete branch you linked earlier. I followed all of of your instructions thoroughly in the Compilation Instructions, but I seem to be getting an error related to compiling The firmware in eclipse...

I'm able to Compile/Clean CoreNG, but as soon as I compille reprap errors I get the attached error msg...0_1535197305255_errorlog.txt

Thanks guys! Any help is very much appreciated.

dc42

File RepRapFirmware.h in my fork of RRF doesn't have that definition of type interruptMode.

streamliner

@dc42 that's exactly what I came up with... tracing it back manually now. This is work I am picking up on; it's possible that they utilized a local lib to compile the prior version. Thanks and I'll respond to this thread once I finish and pull in the correct function. I am also going to be re-initializing our public repos over the next couple of days. We'll constantly be maintaining 12864 functionality for the crane line, so I hope that this will be an additional resource that I can assist the community as a whole with.

Cheers!

David

streamliner

@dc42 Okay, took some manual searching/diffing but I found it.

Looks like it's actually in CoreNG/cores/arduino/wiring_constants.h in the v2-dev branch. In fact, it's defined in every branch of CoreNG except for 'dev'. In case you'd like to compare:

https://github.com/dc42/CoreNG/blob/dev/cores/arduino/wiring_constants.h

All except the dev branch of that file contain this:

enum InterruptMode {
INTERRUPT_MODE_NONE = 0,
INTERRUPT_MODE_LOW,
INTERRUPT_MODE_HIGH,
INTERRUPT_MODE_CHANGE,
INTERRUPT_MODE_FALLING,
INTERRUPT_MODE_RISING
};

My thought was: Okay, I will use the v2-dev branch of CoreNG and RepRapFirmware -- this was just assuming the convention was valid to my understanding. My next move is to try the CoreNG dev branch. Any other thoughts here?

Next I am going to look into the benefits of including FreeRTOS as it relates to the Maestro/Quad.

Thanks Again

~David@M3D

streamliner

Well; using the dev branch just led to another set of errors... total shift. I believe something is simply not correct in our branch structure. Gotta get out the Chainsaw for this one... We have a lot of files nested where they shouldn't be.

~David

streamliner

@dc42 I'm going through commit history to determine what has happened.. it looks like at some point the project file for the 'v2-almostcomplete' build was removed from gitignore and became part of their ongoing updates to the m3d Repo... I'm trying to determine teh best way to unravel this.... is there anything I could do to simply assist with the merge?

dc42

We've been using the v2-dev branch for both CoreNG and RepRapFirmware for the last few versions. The only build of RRF for the Maestro that I maintain is the FreeRTOS build.

streamliner

Thanks @dc42 -- I think I am getting close to determine what happened here... I plan to take on as much Maestro-specific stuff as I can. As far as getting us back on even footing... do you have any suggestions on going forward? Right now i'm doing a full folder diff between the v2-dev branch and the v2-12864nearcomplete branch on our side.

He has added a very substantial amount of Menu Items.. I am attempting to abstract them now. If you have any suggestions for how we can abstract this, I'm all ears... otherwise, I'll finish up here soon enough.

Also -- I'm still fairly new to the FreeRTOS concept, do you think the Maestro would benefit from a FreeRTOS build(or is that the public build?).

Thanks

David

T3P3Tony

@streamliner

@dc42 said in Maestro getting started:
The only build of RRF for the Maestro that I maintain is the FreeRTOS build.