Maestro getting started

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.

dc42

@streamliner said in Maestro getting started:

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.

Please read the provisional documentation that I wrote at https://duet3d.dozuki.com/Wiki/Duet_2_Maestro_12864_display_menu_system. I don't know whether he followed that documentation accurately or not. The message I received from him some time ago suggested that he hadn't implemented "image" but he had done the rest.

streamliner

@dc42 In Fact -- I believe he followed it exactly, and as you say the only thing that I can't find is the Splash Image -- that's no problem. It seems nearly complete.

Now, I tried simply merging over his changes to the menu and associated files, but still ran into an error. I am actually getting my macos devmachine up again so I can use xcode... Eclipse is killing me. I use this machine for a lot of MCU prototyping and I think I am just getting a lot of conflicts because of this.

I'm restoring my mac workstation tonight and will establish n proper project tomorrow. I may have a few more questions for you; soon this will all be a lot smoother.

Thanks you for your time!

Cheers!

David

StJohn

Hi, I have just purchased the Duet 2 Maestro, and so far this has not been a happy experience.

I cannot get the board to communicate with a PC at all. When a USB cable is plugged in I get 3 LEDs lit one green and two red. A blue led briefly flashes on the WiFi board and the Diag. led flashes once.

The board is not recognized at all when plugged in. I have manually installed the drivers for the board on both a laptop and PC with no difference between the two. I would try updating the firmware manually, but even this seems to be impossible as there is no erase button that would allow me to force the update to the board. The USB cable is taken from my other 3dprinter where it connects the Smoothieboard to a Raspberry Pi to for OctoPrint.

I did manage to get the Diag led to light by creating a custom config.g and other files using the RepRap configurator, however the network connection still did not work nor would the new config. files allow the board to communicate with either my PC or laptop.I copied these files to the SDCard by installing it in the laptop, as apparently the SD Card cannot be accessed through the USB connection.

After metaphorically pounding my forehead to a blood soaked pulp, is there anyone who can help me as I am now at a complete loss, having spent several hours only to end back where I started. I will answer as best I can any questions.

Please help.

dc42

Support for Duet Maestros sold by M3D (which is all of them so far) is provided by M3D, not by us, because M3D does the manufacture and testing. However...

I have heard of several cases of the micro USB cable supplied with the Maestro being faulty. So I suggest you try a different cable. [EDIT: looks like you are already using a different one.]

The Maestro doesn't have an erase button, it has a 2-pin jumper instead. It is close the the main processor, labelled ERASE.

I don't understand:

A blue led briefly flashes on the WiFi board and the Diag. led flashes once.

What WiFi board? The Duet 2 Maestro has an Ethernet connector.

HTH David

StJohn

OK, I am confused, the board has Wifi, but no erase button. It seems to follow the general layout of the Duet 2 but so does the Maestro. There is a jumper just below the endstop connectors marked erase, no ethernet connection but has wifi. I purchased it a few days ago from E3D online as a Duet 2. Do some Duet 2s not have an erase button?.

I guess I will jumper the erase pins and boot the board. Then try to reinstall the firmware. Unless someone can suggest a less drastic course of action.

dc42

@stjohn, what you have is a Duet WiFi revision 1.04, not a Duet Maestro. So you've come to the right place for support, although you're in the wrong thread.

If your PC uses Windows, please go to Device Manager, then connect the Duet via USB. Expand "Ports (COM & LPT) and look for the Duet there. If it isn't there, see if there is an "Unknown Device" listed anywhere. Also try a different USB port - Windows has a habit of turning them off sometimes. Try a different micro USB cable if you have another one.

If you still can't find the Duet in Device Manager, you can try putting a jumper across the Erase pins. The "Bossa port" should appear, again under "Ports (COM & LPT)". Remove the jumper again, because the board won't program while it is present. Then follow the instructions at https://duet3d.dozuki.com/Wiki/Installing_and_Updating_Firmware#Section_Fallback_procedure_Num_3.

HTH David

crussty

@streamliner Watching along as you unravel this. Don't envy you having to sort it all out. Once you get it sorted, would you mind also posting the compiled bin's in your dev branches so we can fiddle with what you are working on without having to rebuild it?

Mahalo!

Chris

streamliner

@crussty Most certainly I am just trying to determine where the 'fracture' ocurred right now... this is not fun. I think I may just pick up on the most complete version of what @dc42 has and just update it inline.

@dc42: Speaking of, what branch of your dev firmware is currently the most similar to the feature branch: https://github.com/PrintM3D/RepRapFirmware/tree/v2-feature/morecomplete12864? I see what happened at this point...he was going to implement the feature branch, had to stop, and somewhere in between would have been an update.. i'm trying to construct a timeline to understand where to go back to.

Thanks,

David

dc42

As discussed by email, I have merged Matt's work into my v2-dev branch.

StJohn

Thank you for your help. I went back to basics on this issue and dug out several USB cables and tried the board with them until I found one that worked. I have now connected the board to wifi and tested it. Everything seems to work so no nuclear option was needed. Thank goodness..

One odd thing I noticed. When homing individual axes the Z axis would move first. This caused the head bed to collide with the printhead. I have edited the homing .G files to prevent this. Now I am waiting upon a bed-levelling sensor. But all of this is for another time.

dc42

@stjohn said in Maestro getting started:

One odd thing I noticed. When homing individual axes the Z axis would move first. This caused the head bed to collide with the printhead.

The standard homing files move the head up (or bed down) by 5mm before homing X or Y, to avoid dragging the nozzle over the bed if it is at Z=0. If on your printer it caused the head to collide with the bed, then it sounds like your Z axis is moving in the wrong direction.