Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Custom firmware development
Excellent !!! Thanks a lot for your work and your explainations. :woohoo:

For FW maintenance point of view ,I would suggest to keep same as 1.0 to leverage all update especially because 1.0 and 2.0 are same hardware.
I would suggest for the screen and name to use a test compilation based on the number of extruder defined in configuration.h

#define NUM_EXTRUDER 1

so just need to add a IF condition about NUM_EXTRUDER in uimenu.h and configuration.h
This is just my opinion,

Thanks again,

I read your variant.cpp
you use PC28

but for me PC28 is known and is the one for direction
PC28 is PWM3 pin 139 arduino 3, Motor E2 Dir

Sorry to ask but why use PC28 for your pin 128 ?

Additionnaly, may I know also what sketch action do you use to check to test motor enabled pin ? I am willing to learn

Edit: I have uploaded the pinout I completed based on schematics ( - but I may be wrong
Edit2 Aaryn:I found some typo mistake in your files so just share raise point to you
in pins.h
#if NUM_EXTRUDER=2 should be #if NUM_EXTRUDER==2 miss one =

in userpins.h
#define ORIG_E0_DIR_PIN 121

these lines are duplicate after with other values
#define ORIG_E0_ENABLE_PIN 123
#define ORIG_E0_STEP_PIN 98
#define ORIG_E0_DIR_PIN 121

In Configuration.h
#define EXT1_X_OFFSET 2880
"xOffsetSteps": 2880,
How did you get these values ? I did measurement on my da vinci and distance between 2 holes is 35 mm so when I use the value : #define XAXIS_STEPS_PER_MM 80, I got 35x80 =2000 not 2880, did I do something wrong ?

I asked you to correct me and you did a wonderful job. Thank you

I have attached a new zip file with all of the corrections you mentioned. I am testing these changes on the printer now. I will let you know how it goes.

Yes, I got the E1 direction pin and the Enable pin mixed up in my notes. The real Enable pin uses PIO_PB22. The zip file has a corrected variant.cpp
I have also included the sketch I used to verify that the enable pin was correct. Read the comments in the sketch.

Thanks for the new Pinout file

I removed the duplicate lines from the userpins.h
I fixed the == in the configuration.h
I also changed the 2880 to match your 2000. Your logic makes perfect sense to me. That 2880 number was auto generated. I had measured 36 MM between the extruders but I was not being exact.
I had some trouble with it switching extruders in the Repetier host software. But I solved the issue. See the next post.
It WORKED!!! I had to play with the EEProm and eventually decided to switch the two Extruders in the firmware. So now I have Extruder 1 on the left and Extruder 2 on the right. But now it works!
I have attached my last zip file with the changes in the userpins, configuration, pins, variants files. This zip also includes my EEProm so you can import that.

Open Repetier host. Connect to the printer. Clicked the Menu Config>Firmware EEprom Configuration. Use the import button at the bottom.

Next things on the to do list. will be to upload my final work to the repository.
Hi I do not follow the logic between just to exchange the 2 extruders pins and the eprom data saving - can you develop more ?

also if you invert extruder 1 and 0 you must also apply this to X offset values or put a negative X offset values to extruder 1, if not, the origine reference won't be correct, single extrusion won't be centered, and dual extrusion won't result as expected

I have also noticed you changed for X offset from 35mm and 2000 steps to 36 mm and 2800 steps, if 36 mm should not be 2080 steps ?



Edit : looking at the code, eeprom need to be reset using restoreEEPROMSettingsFromConfiguration() fonction but I do not see it in menu
anyway this can be done by sending gcode commands M502 to reset then M500 to save to eeprom - it put all configuration.h values to eeprom,
Aaryn I have modified the pin.h to be able to use same code between Davinci 1 and 2 by adding a condition on number of extruder on #define SENSITIVE_PINS
Same for uimenu.h
UI_PAGE4(ui_page1,"\005%ec/%Ec\002B%eB/%Eb\002","Z:%x2","Mul:%om Buf:%oB","%os");
UI_PAGE4(ui_page1,"Right \005:%e0/%E0\002","Left \005: %e1/%E1\002","Bed: %eB/%Eb\002","%os");

On mine I removed Z position, buffer and % speed to have a clear and simple screen on my 4x16 LCD,( I enclose screen picture) anyway information are available in others screens if you do navigate, but feel free to change it is easy to customize.
I did not noticed any other screen that need modification but have a look.

I have compiled and uploaded FW with NUM_EXTRUDER values 1 and 2 and it works without error, that would help to avoid to maintain 2 branches in repository

PS : I did not used the inverted pins as using M502/M500 commands in repetier allowed me to have correct eeprom data. Now I guess it is time for some prints to check the values, ^_^

You rock! Thanks for making it backward compatible with the DaV1. I really like the idea of keeping them on the same on the same branch in the repository.

Here is the long story of why I ended up switching the two Extruders. For this post I will call them ELeft and ERight.

The first problem I had was the EEProm was blank for all the second extruder settings. So when I would switch from the default ERight to the ELeft it thought they were in the same spot. It also thought that 0 steps per MM was how to extrude. I fixed those values in the EEProm and both extruders started to work. I found a problem in the math we used for the X offset. 35 * 80 = 2800 not 2000. 36 * 80 = 2880. So your measurement of 35 mm was correct. I used 2800 as the X offset for ELeft. It all seemed to work correctly. It even printed correctly. But when I attempted to HOME X then Y. Bad things happened.

You can test this with your current setup but don't home Y because it could break something. In Repetier host select the ERight and you will notice that the entire tool head moves 35 MM to the left. Even if you home the X. It will go all the way home then move back 35 mm. This isn't bad by itself. But if you leave the tool head at this X location then try to Home Y. VERY BAD THINGS happen. It will smash the tool head into the back of the bed assembly and make lots of grinding noises. So I had to figure out a way to make the machine have the ELeft selected before it would home X then Y. I chose to just make ELeft the default Extruder (aka Extruder 0 in the firmware). I did have to tell the EEProm that ELeft is now -2800 offset from ERight. Now that I have had a night to think about it though it is still possible for a user to have ERight manually selected and still try to home X then Y. Maybe we should look into changing the Firmware so it will always have E0 selected before it homes X and Y? That would prevent it from crashing the tool head into the bed assembly. What do you think?
Hi Aaryn,
my bad .. I am getting old and cannot count properly anymore :oops:
Yes it seems the reference extruder is the E1 and not the E0 for home - the home code in fw is in printer.cpp (void Printer::homeYAxis()) should have a way to force extruder - will have a look also

EDIT: I found that firmware is doing home according selected extruder by default it is 0 but seems not working,
for(uint8_t i=0; i
I finally got my printer back and update to newest firmware form BGM370's davinci branch.
Seems the newest update break the Optoprint to establish connecting (waiting for keyword "wait") and the status display in Repetier host ( shows "Wait" all the time in the log area)
In Configure.h WAITING_IDENTIFIER in reprap is always "wait", one of the patch change it to "Wait" breaks most software's connection test.
So to fix it find this line in the Configure.h
and change it back to

After reload the firmware the connection issue should go way.

Have fun printeing
I proposed the correction BGM because I think it was me who had changed it (I like capitals Smile )
It seems one of the most annoying problems of the Repetier firmware is the display corruption... it happens quite often. I've been running a build from bgm's branch for a while and sometimes it takes turning the printer off and on again several times to get the display to work properly. Today I installed a build from Edouard's branch and it seemed to be working better on the restarts but after a while on I'm also getting display corruption. Do we have any idea what's causing this and/or how to fix it or is it some annoyance that we'll just have to learn to live with?
I've never seen that problem, but I remember a while back several people had damaged flex cables running from the display to the controller PCB. Maybe it's hardware?
Hmm, really? I had simply assumed that it was a glitch of the firmware... no one else suffering this issue then? It never happened with the XYZ firmware though.
I can't seem to find the post with the pictures and all, but a few printers had the LCD ribbon cable damaged up near the display. This was early on, so it may not have anything to do with it, but a loose ribbon cable is a possibility.
I have the same problem with lcd menu, it happens when you select to home all or any axises , usually after homing the item for home all disappeared but still selectable .
I resolved my issue with this by changing the UI_START_SCREEN_DELAY to 4 seconds instead of 2.

In configuration.h

find #define UI_START_SCREEN_DELAY and change it to 4000
Thank you, I'm definitely trying this. I guess it should help with having a blank display upon turning on the machine at least... not so sure it'll have any impact on pure display corruption that appears just sometimes while using the machine though...?

Yes I also have this bug and it comes from the firmware. About one of 10 times, the printer does not start. And when I run the extruder with the LCD display sometimes freezes.

Normally, I think the team will Repetier fixed these bugs in the new version because I've seen a lot of change on the menu in this version (0.92)
In repetier the home functions disapear after been used - they are back to visible if you use x / y / z position change
to have them permanently visible just remove the filter in uimenu.h

so commands will become normal commands without hide/show filter

It is what I use on my FW

Forum Jump:

Users browsing this thread: 4 Guest(s)