Marlin: Loss of digital trim-pot control by g-code command on Printrboard rev F6

[avidtech]

After compiling and flashing my new F6 (had an F5, ripped the serial port off the board x( ),
I can no longer adjust the digital trim-pots, or get the serial to print the settings for the trim-pots specifically, using M907-910. Using arduino 1.6.5-1.6.9 and updating libraries made no changes.
Am I missing something here? I thought the trim-pot control was on the I2C bus, it worked well before, even though the current values were not printing to log over serial, I could change them, now, I get no response. Using latest build as of this post. Again, everything else is functioning very well, better than the last RC, overall. I am uncertain if the rev F6 board has a variance in pin-outs (from F5) that needs to be accounted for.

Thank you in advance! And a big thanks to all the devs here, this is wonderful project!

[thinkyhead]

This sounds like a good question for @printrbot.

At the time we added support for Rev F it sounded like we had a good handle on these trimpots. What was flashed on the board before you updated to the latest Marlin – an earlier Marlin, or their custom fork?

Is it just the motor current, or also microstepping modes? (Does the board do both?)

The relevant settings that you can play around with in the pins file are…

// uncomment to enable an I2C based DAC like on the Printrboard REVF
#define DAC_STEPPER_CURRENT
// Number of channels available for DAC, For Printrboar REVF there are 4
#define DAC_STEPPER_ORDER {3,2,1,0}

#define DAC_STEPPER_SENSE    0.11
#define DAC_STEPPER_ADDRESS  0
#define DAC_STEPPER_MAX   3520
#define DAC_STEPPER_VREF     1 //internal Vref, gain 1x = 2.048V
#define DAC_STEPPER_GAIN     0
#define DAC_OR_ADDRESS    0x00

Some digital control settings in Configuration_adv.h…

// Microstep setting (Only functional when stepper driver microstep pins are connected to MCU.
#define MICROSTEP_MODES {16,16,16,16,16} // [1,2,4,8,16]

// Motor Current setting (Only functional when motor driver current ref pins are connected to a digital trimpot on supported boards)
#define DIGIPOT_MOTOR_CURRENT {135,135,135,135,135} // Values 0-255 (RAMBO 135 = ~0.75A, 185 = ~1A)

// Motor Current controlled via PWM (Overridable on supported boards with PWM-driven motor driver current)
//#define PWM_MOTOR_CURRENT {1300, 1300, 1250} // Values in milliamps

// uncomment to enable an I2C based DIGIPOT like on the Azteeg X3 Pro
//#define DIGIPOT_I2C
// Number of channels available for I2C digipot, For Azteeg X3 Pro we have 8
#define DIGIPOT_I2C_NUM_CHANNELS 8
// actual motor currents in Amps, need as many here as DIGIPOT_I2C_NUM_CHANNELS
#define DIGIPOT_I2C_MOTOR_CURRENTS {1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0}

Any one of these might have changed for the new board. We can peek at the Printrbot fork and see if they have any recent changes affecting these.

[thinkyhead]

The Printrbot fork also currently includes in Configuration_adv.h…

  #if defined(PB_PLAY)
    #define DAC_STEPPER_CURRENT {70,70,70,65,65}
  #elif defined(PB_SIMPLE)
    #define DAC_STEPPER_CURRENT {50,50,60,60,60}
    #define DAC_STEPPER_CURRENT {70,70,60,60,60}
  #elif defined(PB_PLUS)
    #define DAC_STEPPER_CURRENT {60,65,60,65,65}
  #elif defined(PB_MCF)
    #define DAC_STEPPER_CURRENT {20,20,20,20,20}
  #else
    #define DAC_STEPPER_CURRENT {50,50,60,60,60}
  #endif

[thinkyhead]

The Rigidboard pins file also defines:

#define DAC_DISABLE_PIN     42 //  set low to enable DAC

Perhaps a newer DAC uses this too.

[avidtech]

Thank you for the rapid response,
When you order the boards from PB now, they force you to buy one preflashed of course. I usually do an erase pass when I flash a new base FW, without problems. If the pointers on the last RC used are the same, that it would be logical to look at the PB fork. Notably, if I change the variables defined as you posted, the stepper scaled values, even after an eeprom blank, still getting the same overdrive.

I will poke around a bit and see if I notice anything, but I doubt I would find relevant enough information as fast as you guys. I will also try a few different DAC variables and see if I get results.

[thinkyhead]

Well @printrbot is a good organization, and respectful of the obligations of the GPL. If you ask them for the source code that was flashed onto your board, I am certain they will furnish it to you. It might be on their website or elsewhere already. I'm not sure if it actually corresponds to the code in their Marlin fork at this time.

[Roxy-3D]

Well @printrbot is a good organization, and respectful of the obligations of the GPL. If you ask them for the source code that was flashed onto your board, I am certain they will furnish it to you. It might be on their website or elsewhere already. I'm not sure if it actually corresponds to the code in their Marlin fork at this time.

@printrbot
Yes. All of that is true. And my first printer had (and still has) a PrintrBoard in it. I am very sentimental towards my first printer. Please check out: (https://github.com/MarlinFirmware/Marlin/issues/3966#issuecomment-225245174) just so you know I'm loyal to my 1st printer. (When you follow the links to 3D-PrintBoard and read the threads... They are many years old and talk about PrintrBoards)

I'm ready to pull the plug on that DAMN PrintrBoard. If they can't spend a couple of hours getting Arduino v. 1.6.x working on it, I'm going to put a RAMPS v1.4 board on that printer. I would prefer to leave it as it was... But I can't even load the current Marlin on it. F&%$# PrintrBot !!!!

@thinkyhead Scott: Please also be aware of the fact that PrintrBoard owners are being told to use version .22 of Arduino. I managed to get Arduino v 1.05 working with my PrintrBoard with the help of some posts that Linkomatic's did. The whole reason we decided to keep old versions of Arduino from compiling Marlin was we had too many unexplained compiler bugs. My guess is a VERY old version of Arduino is being used. If so... There is no telling what compiler bug is happening....

[avidtech]

I have spent a while going through everything, haven't made any progress. Everything looks correct, double checked libraries etc, and I didn't find any evidence of change between the HW revisions on the side this should be concerned with. I have been up for more than 24 hours, I will try again tomorrow.

[avidtech]

I am waiting for a response from PB about changes in rev F6.
For now, I found a klugey workaround, flashing the plus hex file, testing/changing the pot values, and THEN flashing the Marlin RC does work. Any information I get from PB, I will post it here.

EDIT: Changing any of the DAC values in source has no effect after blanking and recompiling.
I have not heard anything from PB after a few days now, so I explicitly requested the new source to find the discrepancy. After the last Marlin RC, this is literally the only feature that is bugged (in my experience). Even the full matrix bed leveling works this time around, I am very happy. :)

[Roxy-3D]

Even the full matrix bed leveling works this time around, I am very happy. :)

You will be more than 'very happy' soon... I'm working on a Mesh Validation Tool (command) to help certify the new bed leveling system.

[avidtech]

Doesn't look like my last comment posted, rewriting;

PB support responded to me, the staff doesn't have the F6 boards on hand yet, I must have picked up from the first batch. I was pointed to the fork again, but I am not seeing any differences in the source.

Taking in the entire RC from scratch is taking me a bit of time, I am doing what I can to re-familiarize myself as rapidly as possible. Could this be related to #3182 or #2971 ? I have yet to determine if the issue is within the I2C bus addressing, or if this could be related to the MCP47xx communication. The only ACK I log is OK, with no other information, as of right now.

EDIT: I will add my suspicion is leaning towards I2C, as this HW revision did away with the external I2C 4-pin.

[thinkyhead]

Could this be related to #3182 or #2971?

Those PRs added initial support for Rev F. so I would say so.

Also note the changes in #4159

[avidtech]

Ah, I see the difference now. I went through the mc datasheets to make sure there weren't any changes in DAC revisions, no different pinouts, same address schematic as before(within the DAC), etc. I compared the DAC to my other PB rev F5, same chip and traces. I'm starting to look through the PB fork's dac_mcp4728.cpp file now, but I am far from talented with software.

[avidtech]

PB got back to me again, after running some tests for me, apparently, they have no issues with flashing using the printrboard update software. I have no experience with it, I have always flashed with flip with negligible to no problems.
I'm running a 48 hour print job right now, after that, I'll give a shot and see what happens using my compiled binary instead of the pre-compiled bins available from PB.

[StephS]

Need to get schematics of the rev F6 board. I haven't tried the latest RC on my Rev5 board, but it's possible that it's broken if the pinout is the same as the Rev 6.

[avidtech]

I would test it on my F5, or what's left of it, can't get it working after the physical damage. For now, I'm just flashing the pb precompiled binary to make the changes, then moving back to the Marlin for operation.

[thinkyhead]

I wonder if it would be possible to figure it out by taking a very close look at the board with a magnifying glass, following the traces, writing down the chip numbers, etc. Then we can check the datasheet for the specific components and find out how they expect to be bit-twiddled.

[avidtech]

I already did.
All of the traces are the same, the DAC is a 4728UN, the generations appear to be the same, as best I can tell. This one still has me wondering.

Even in the PB fork, they use the same address assignment, then again, it's also possible they haven't found an issue with the F6 boards, logistically, as the support team did not yet have them on hand when I asked about it.

[Roxy-3D]

For $4.37 (including shipping) I got a RAMPS v1.4 board on eBay. And for $8.73 I got a Mega processor board. I'm done dealing with that PrintRboard on my system. I would have liked to keep my first printer totally intact, but I can't even load the latest Marlin on it.

[thinkyhead]

@avidtech Any chance you just got a bum board?

[avidtech]

I don't see any evidence supporting bad hardware. The feature does function with the PB fork.

PB didn't really give me an answer, just kind of gave me a shrug and closed the issue.

[thinkyhead]

The feature does function with the PB fork.

@avidtech Right, of course, you did say it was working with their fork. Is it the fork posted publicly on Github that works for you??

I guess we'll we have to do some clever detective work to figure it out. If their published code works, we just need to read through and find out what's different from what we are doing.

[avidtech]

Yes Scott, I agree. I'm unsure what else can be done. I'm sure you guys will be sharper with it than I could be. Again, the only hint of change on the i2c bus is the removal of the 4-pin i2c molex and associated pins, however, in their source, the addresses and printouts remain the same. Very frustrating!

[avidtech]

In RC8, uncommenting #define Digipot_i2c (for Azteeg X3 Pro) in configuration_adv.h now allows this feature to work as intended.

[fiveangle]

I'm trying to unwind this too, due to recent conditional added in #5792 (as Bob identified in #6113,, which I also hit when attempting to move from @Sebastianv650 's unified timer branch (RC7-based) to RCBugFix).

In Configuration_adv.h we have:

// Motor Current setting (Only functional when motor driver current ref pins are connected to a digital trimpot on supported boards)
**_#define DIGIPOT_MOTOR_CURRENT {135,135,135,135,135} // Values 0-255 (RAMBO 135 = ~0.75A, 185 = ~1A)_**

// Motor Current controlled via PWM (Overridable on supported boards with PWM-driven motor driver current)
//#define PWM_MOTOR_CURRENT {1300, 1300, 1250} // Values in milliamps

**_// uncomment to enable an I2C based DIGIPOT like on the Azteeg X3 Pro
//#define DIGIPOT_I2C_**
// Number of channels available for I2C digipot, For Azteeg X3 Pro we have 8
#define DIGIPOT_I2C_NUM_CHANNELS 8
// actual motor currents in Amps, need as many here as DIGIPOT_I2C_NUM_CHANNELS
#define DIGIPOT_I2C_MOTOR_CURRENTS {1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0}

And in pins_PRINTRBOARD_REVF.h we have:

**_// uncomment to enable an I2C based DAC like on the Printrboard REVF
#define DAC_STEPPER_CURRENT_**
// Number of channels available for DAC, For Printrboar REVF there are 4
#define DAC_STEPPER_ORDER { 3, 2, 1, 0 }

#define DAC_STEPPER_SENSE    0.11
#define DAC_STEPPER_ADDRESS  0
#define DAC_STEPPER_MAX   3520
#define DAC_STEPPER_VREF     1 // internal Vref, gain 1x = 2.048V
#define DAC_STEPPER_GAIN     0
#define DAC_OR_ADDRESS    0x00

Printrboard RevF has potential to support 5 digital trim pots (including second extruder when expansions board installed as on Plus with dual extrusion upgrade)

Nowhere does _DAC_STEPPER_DFLT_ exist outside of supporting just the RIGIDBOT that I can find.

Thoughts ?

-=dave