A few questions about the functionality of SmcCmd (used under linux though this should be the same for all platforms).
SmcCmd -h doesn’t show an option to allow updating of the Speed Update Period. Is a good method for changing this update period to do a SmcCmd --getconf to create an xml of current settings on the SMC, edit that xml file to change the 0 tag, and then use SmcCmd --configure to load the new setting? Or is there a ‘hidden’ command in SmcCmd to set this attribute?
Also, can a xml config file taken from a SMC 18v7 be loaded onto different 18v7 controller? Can that 18v7 xml conf also be loaded onto say a 18v15 or 24v12? (Assuming firmware is the same between controllers or are xml conf files typically firmware independent?)
Last question, i see there’s a --restoredefaults option that resets the controller to factory settings, is there a command to resets basic limits (speed,accel,decel,brake duration) to the boot loaded (yet non factory) values without power cycling the controller?
SmcCmd has no hidden options; you can read its source code in the Pololu USB SDK to check. I recommend finding one speed update period that will work for you instead of changing it on the fly. The speed update period (along with all the other configuration parameters) is stored in flash so it takes some time to change it and the flash is only rated for 10,000 erase/write cycles.
Yes and yes. The firmware on the different models of controllers are slightly different but the settings they support are all the same.
There is no command for that, but I’m pretty sure that you could achieve that by setting each parameter to its least-safe possible value. For example if you try to turn off the acceleration limit by setting it to 0 or 3200 the controller would instead use the setting in flash. The rule is that you can never set a parameter on the fly to be less safe than the Hard Motor Limit parameters in flash.
Is it documented somewhere which settings are applied to flash and which are runtime only?
If it’s not documented, are the following all runtime?
--stop stop the motor
--resume allow motor to start
--speed NUM set motor speed (-3200 to 3200)
--brake NUM stop motor with variable braking. 32=full brake
--getconf FILE read device settings and write to file
--max-speed NUM (3200 means no limit)
--max-speed-forward NUM (3200 means no limit)
--max-speed-reverse NUM (3200 means no limit)
--brake-dur NUM units are ms. rounds up to nearest 4 ms
--brake-dur-forward NUM units are ms. rounds up to nearest 4 ms
--brake-dur-reverse NUM units are ms. rounds up to nearest 4 ms
Noticeably missing is starting speed, which is unfortunate since this can be temperamental when using batteries, but I saw this in the source which indicates for sure it’s not runtime:
unsigned short startingSpeed; // Minimum non-zero speed (RAM value cannot be changed by serial/USB); maps to scaledVal==1 in RC/analog mode (0-3200). 0 means no effect.
The serial equivalents of those commands are documented in the “Binary Command Reference” of the user’s guide. There are probably also some good comments in the source code of the Smc class (Smc.cs). All the commands you listed are for run-time (RAM) settings except --getconf.
The Starting Speed parameter only has an effect in RC or Analog mode so it shouldn’t matter to you; what would you want that parameter to do when you are controlling the SMC from a Raspberry Pi?
Many DC motors used for RC/models don’t begin to to spin until 3v-7v depending on the motor(s). Large scale model garden trains are what I’m working with and for any train, slow speed movement (sometimes less than 5 rpm) is critical part of the functionality. Depending on the age of the train, how many motors in it (1-4 in series), and the type of motor(s) that low rpm value varies from locomotive to locomotive. Since most people won’t want to specify a value such as 1273 for a target speed, the control will be 0%-100% and it would be best to be able to specify a 1% and get <5rpm but finding that target speed that barely moves a motor could potentially change at every use session (or during use as the battery capacity is used up and motors warm up or cool down) thus having a ‘trim’ that can be adjusted per operating session without writing to the flash would be nice. Some of this ‘trim’ can be done in software of course, or by using a JRK instead.