@mjrice, are you planning to port your changes to marlin 1.1? Reading through several posts on other message boards, it seems there is improvements to both autohoming and LCD support. After combing through your fork and the mainline source to get the reprap full graphic LCD working, it seems like it there is a lot of changes.
Yes, I am going to try to resync my fork with the main branch within the next couple days. Let’s hope I don’t break something
Very cool. Looks like others are adding their modifications to ‘example_configurations’ as to not disrupt the mainline. There is already code in the mainline for Z_PROBE_SLED. Maybe your code for “Z_PROBE_RACK” can be merged upstream?
Might be more straighforward to try to push your feature to Marlin-Dev branch and have it release in the next RC?
Itmight not be that trivial with all the chances that was made lately tho.
One thing I’m having a hard time is the new folder layout with Configs in separate folder that let you chose the printer in the Arduino IDE.
I’m using Visual Studio with Visual Micro plugin to compile the arduino project and it’s a pita with the new setup.
looking forward to the marlin 1.1 sync @mjrice
Ive been working through some motherboard/LCD issues mainly because of me using mini-rambo board ( not ramps ) with full graphics lcd.
In the current wilson2 marlin i cant seem to choose the right motherboard + get LCD to display
#define MOTHERBOARD 302 does not seem to work
i can make the mini rambo + LCD work in the Marlin ( main line ) but then alot of the nice settings / features from your wilson2 fork wont work or compile.
If anyone has a working firmware/file for wilson2 compiled for Mini-rambo board it would be greatly appreciated!
if not i will just wait till you update to marlin 1.1 and go from there…
Nice increase in print quality with Marlin 1.1 RC8
So my PICA board 5v was somehow fried when I plugged into my laptop. I could still print but I had to supply 5v via USB and the LCD was glitchy. Anyway, I ended up purchasing a MKS Base v1.5 board and the last few days I setup Marlin 1.1 RC8 on it.
For firmware, I copied many of the settings from mjrice fork except for the complex bed leveling servo and rack code. I ended up sticking on an inductive probe with some foil under the glass (my aluminum bed arrives today). I enabled automatic bed leveling with G29.
I’ve been amazed at the first few prints. I’ll continue to test with same filament I was using prior and report back. I have yet to compare ABS prints but I’m optimistic.
I believe it is due more to software than hardware as the MKS Base v1.5 is still based on ramps.
I’ve uploaded my configuration.h file if anyone is interested.
I decided to fork the Marlin repo and merge in the stock config with Jarret’s and it does appear to boot at least. There are some moves that need to be added for the probe rack setup, but the auto leveling and other prepare functions work. I’m going to try a simple cube print to see what happens.
Here is the fork with the configuration.h changes committed to a new WilsonII branch.
Since I switched over to an inductive probe, I switched to RC8 and has been smooth sailing.
Only complaint: every time you connect in pronterface, the whole machine reboots. I don’t recall that happening before.
I finished up some tweaks to the configuration to get things working with the rack probe setup, without having to modify the firmware with extra moves.
I have no idea if the servo probe settings I also brought over will work for that setup.
FYI, I have started merging my stuff into the latest Marlin RC base - it’s taking some time because a lot in the project has changed since I originally forked it.
Have you considered adding the code needed to retract the probe in the following define:
That would minimize changes needed to support the wilson 2. The other option is to utilize:
Which is similar kinematics to the pinion.
Initial layer is heaps better with the bilinneal levelling routine.
I think I will up it to more than my current 16 points to try and get it really tuned in.
Unfortunate that you can’t save the matrix yet, so have to redo every time.
That’s what I ended up using for the rack setup and set an end script to put the probe away. It works for the auto leveling routine, but doesn’t for autohome because the end script isn’t run.
@mjrice Have you any ETA for the completion of the merge? I am wiring-up my Wilson II at the moment and about 2-weeks away from integrating Marlin into my Rumba board.
I don’t know when the changes will be in the main Marlin project, but you can get my version which is what I requested the pull from. It is in the fork “RCBugFix-mjrice” here:
The original code (which I’ve been using for a year almost) is still archived here:
It was way too much trouble to try to merge my original code with the newer RC branch, which is why they are two separate projects.
Another follow-up to my last message to clarify - When you go to github to get the new firmware, you’ve got to pick the branch as shown here, otherwise you won’t get the correct code:
And (this part is important!) you’ve got to replace the configuration file with the one named “Configuration_mjrice.h”. Just rename the file “Configuration.h” to something like “Configuration.orig” and then rename Configuration_mjrice.h to Configuration.h. You can then modify Configuration.h for whatever differences you have (the most important part is probably the type of controller board you have, be it RAMPS, PICA, or whatever). I know it’s a pain; I can’t just archive my configuration without renaming the file or else it will get pulled along to the upstream project which most people wouldn’t like.
Also, here’s a snapshot of my standard testprint made with the new firmware - I’m pretty happy with how sharp it came out:
Is there any reason to stay on the old firmware? And is there a way to backup all the settings I have made to the firmware and EEPROM? I’ve done some PID tuning and acceleration tuning through GCODE that I would like to carry over.
I tried the new stuff from github - and made the changes to enable the Full Graphic Smart Controller.
I tried the same fix as in commenting this out:
#pragma GCC optimize (3)
…but it didn’t do the trick this time.
The screen is almost readable but corrupted similarly as before.
Here is a link to the original problem.