A whole lotta responses...
Quote:
Originally Posted by
Roxy
...I think having the parameters named Xmin, Ymin, Xmax, Ymax is much clearer. The big problem is none of the other GCode commands use long parameter names. And there is no support for the longer parameter names. The support code would not be difficult to do. But....
One idea would be to change the Code_Seen(char ) function to be Code_Seen(char *). It would be very quick to go through the code base (and probably it is just Marlin_main.cpp) to put double quotes around all the existing characters in Code_Seen() functions. We could leave everything else the same where it leaves a pointer looking at the numeric value for the hunted parameter. If we did that... Xmin, Ymin, Xmax, Ymax would work nicely and avoid a lot of confusion for people...
I looked through a bunch of documents about G-code and "standards" and I don't feel that multi-letter parameters is in the spirit. I would propose I, J, K, and L. These are clearly an array but not overly misleading in specificity (e.g. L,F,R,B). Each of these followed by a value in mm.
Quote:
Originally Posted by
printbus
To facilitate merging the updates back into the Marlin trunk, I'd reconsider whether the fork uses the MakerFarm changes to the Type 6 thermistor. The Marlin trunk isn't going to want the Type 6 table changed - there could be people out there used to how it measures temperatures. Your configuration.h file also still contains the now incorrect comment about Type 6 not being as accurate as Type 1 and being created with a Fluke thermocouple. My vote would be to revert thermistortables.h back to the Marlin Type 6 data and change configuration.h to use Type 1 thermistors. Beyond what I concluded in the referenced thread, I think someone said zennmasterM has also said it's OK for MakerFarm people to use Type 1 when they update their firmware as part of his video on auto leveling.
EDIT: BTW - I've been using Type 1 just fine the last week or so. If, for some reason, we're uncomfortable switching to Type 1, the MakerFarm thermistor table could at least be defined as a new thermistor type that is used rather than modifying the Marlin type 6 table.
I have to agree with this. Going back to master on thermistors just makes sense, here is the commit: https://github.com/beckdac/Marlin/co...f473eed821097b
Quote:
Originally Posted by
Roxy
Dacb: Random new topic here: You modified the code to allocate space this way:...
I can't actually take credit for that code, it is from https://github.com/ErikZalm/Marlin/pull/1022
Good catch on the missing free.
Quote:
Originally Posted by
printbus
What? Somebody doing a malloc in Arduino code? Man, my respect for dacb just went up a few notches.
I'm a die hard 'avr-gcc/avr-libc and nice tight hand crafted libs on a Tiny' kind of guy, so I have to confess I don't use the Arduino environment for my AVR projects (but I love AVRs!). Hate the idea of loosing timers and the overhead. I guess with the 2560, this isn't really a problem.
Quote:
Originally Posted by
Roxy
Dacb: I might have successfully cloned your latest branch of the Marlin code on my machine. I made the malloc() changes. But it would not let me sync them. The sync fails because I do not have permissions. Can you grab the code I added?
Also, I attempted to push my Slic3r G29 Post Processing script up into your PlugIns directory. I don't know if that worked either. Can you see it and grab it?
Can you PM me your github username? I'll add you as a collaborator so your commits give you the recognition you deserve!