Added function to DMOC to separate the requestedTorque from the offset to match UQM. The offfset correction has been removed from iCHIP. And so now we send just the torqueRequest consisting of throttle value times max torque. The 30,000 or 32,128 are added in to produce a torqueCommand for CAN.
Added some limitations to iCHIP values so that gauges don't go crazy with a voltage less than the 100v minimum on thevoltage gage for example.
Continued to refine the new variables - most problematic is the reverse input and the enable input. As it turns out, the 255 value is read in our variable as -1.
Added function to DMOC to printout the CAN transmitted torque command values in DEBUG - already in UQM and added TIMESTAMP to DMOC so we can easily see how often those commands are sent.
One of the goals in the last few commits is to rationalize our treatment of systemOperationState (ENABLE/DISABLE) and our direction setGear REVERSE or DRIVE. These have for the most part been kicked upstairs to MotorController parent and are simply accessed from the specific inverter object.
This kind of plays into having an ENABLE input and a REVERSE input as well as an output to turn on the REVERSE light.
The mission here is to push generics UP to MotorController, and inverter specifics DOWN to the inverter object module.
The result has been generally smaller inverter object modules. Probably a good thing.
Not yet dealt with cogently is errors warnings and faults. I kind of intend generics for the Motorcontroller. Specifics in object modules get their choice of the generics to turn on and off.
IF you have specific fault situations in your inverter specific object module you want access to for troubleshooting, have them show up as debug or info Logger statements on the USB serial port. We can support all manner of ugliness there. But the web site should be kept pretty simple, clean and pretty. The philosophy here is for a serial port slum and a web site page upscale suburb.
Added function to DMOC to separate the requestedTorque from the offset to match UQM. The offfset correction has been removed from iCHIP. And so now we send just the torqueRequest consisting of throttle value times max torque. The 30,000 or 32,128 are added in to produce a torqueCommand for CAN.
Added some limitations to iCHIP values so that gauges don't go crazy with a voltage less than the 100v minimum on thevoltage gage for example.
Continued to refine the new variables - most problematic is the reverse input and the enable input. As it turns out, the 255 value is read in our variable as -1.
Added function to DMOC to printout the CAN transmitted torque command values in DEBUG - already in UQM and added TIMESTAMP to DMOC so we can easily see how often those commands are sent.
One of the goals in the last few commits is to rationalize our treatment of systemOperationState (ENABLE/DISABLE) and our direction setGear REVERSE or DRIVE. These have for the most part been kicked upstairs to MotorController parent and are simply accessed from the specific inverter object.
This kind of plays into having an ENABLE input and a REVERSE input as well as an output to turn on the REVERSE light.
The mission here is to push generics UP to MotorController, and inverter specifics DOWN to the inverter object module.
The result has been generally smaller inverter object modules. Probably a good thing.
Not yet dealt with cogently is errors warnings and faults. I kind of intend generics for the Motorcontroller. Specifics in object modules get their choice of the generics to turn on and off.
IF you have specific fault situations in your inverter specific object module you want access to for troubleshooting, have them show up as debug or info Logger statements on the USB serial port. We can support all manner of ugliness there. But the web site should be kept pretty simple, clean and pretty. The philosophy here is for a serial port slum and a web site page upscale suburb.