New XPID software for Arduino UNO/Mega and Sabertooth (with LCD !!)

thanks a lot @vthinsel, I will add this code to the existing one. BTW today I started the rig after one day break and all settings have been reset to default - bug or feature? I did not used the reset button - at least I think so, because I was driving and finished by shutting down the PCs and went off.

PS: The following code

Code:

void SetPWM()
{
   M1.PIDUpdate();
   M2.PIDUpdate();
   ST.motor(1, M1.getPower());
   ST.motor(2, M2.getPower());
}

has to be changed to the one you posted above?

I'm at home now, so I'm updating/testing.... will let you know when I have something neat ready (shouldn't take long).
Values should be stored in EEPROM so should survive on/off. Will check as well.

I have been checking the code more deeply. The first thing it does when receiving a value from XSIM is to map it in the range [min-max] you defined on a motor basis, so we are sure the target position is in the allowed reacheable range. XSIM range is 0-1023 (10 bits), as well as arduino analog range. Based on that I do not really see how you get your symptom. In case your real position is higher, the engine should go reverse to bring you in the range. Is it what it was doing ? Or was it trying to make you completely away ?
Test with XSIM Output testing in Axis output mode: put one cursor to the extreme right or left, and you should see on your LCD the min or max value you defined displayed (the first value after 1: or 2
You may also have a deadzone issue ?

I am at work so I cannot check it out but from memory I can say that I tested the max outputs of SimTools slider but I did not check the values. I was turning the pots and probably I expected there a limitation while the motors were moving. At the earliest Sunday I am off and will do some tests.

If you turn the pots by hand, the code will drive the motor till it reaches the target.
When turning them by hand, you can go past the limits you define of course.
Note: I removed the code from the post af it was not effective anyway.

@vthinsel may I kindly remember you my request to summarize the effects of the values below :

K =
Prop =
INt =
Der =

Thank you.

Update: please can you check the following issue: I want to set the deathzone of Motor 1 to "1", but after saving it and reentering the menue the LED shows "2".

So some weird things happened - I was driving today and after leaving the AC race the rig accelerated like the hell and again bumped into the wall - despite of the emergency flip switches the speed was so high that the momentum was to big to stop fast enough. Until further notice I will not use your code due to security reasons...I hope the error of this malfunction can be found - because it never happened before I think the issue are Sabertooth/Ard/Code releated. One more thing I determined while testing today: I changed the ForceFeedback Min and Max values. After I set the first value the motors were moving like the hell and the rig bumbed (not really) into the wall because I limited the Amp before that to 1A. So I had enough time to react.

I do not post twice, so the issue of the timeout function will be discussed here:
http://www.xsimulator.net/community/threads/smc3-sabretooth-test-version.6236/#post-89737
IMO the problem concerns all Sabertooths so a solution should be appreciated.

Have you asked yourself @Pit, if this is a problem that concerns all Sabertooths, why hasn’t the problem already been addressed then considering some have been using the Sabertooth for years already now, me included?

The problem is not with the Sabertooths imo, it is with the serial coms from your arduino! A serial timeout should only be used to stop a sabertooth during an abnormality anyway, not in an attempt to band-aid a reoccurring issue you are having!

From my dealings, the arduino coms seem to be susceptible to interference caused by high power motors and its wiring being in to close of proximity to the arduino. You also stated the problem happens when your motors are accelerating when they create more interference. If you have not already done so, I suggest you try moving your mega around somewhat to different locations, if possible, to see if you can eliminate the communication issue that way. That has worked for me in the past. If that doesn’t help though, then you might try enclosing your mega with some aluminum foil or a metal enclosure to make a Faraday shield around it. Btw, I don’t need a Faraday shield or shielded wire though for my pots or for the coms.

With that said though, if you wish to add a serial timeout to vthinsel’s modified XPID sketch to try it, just put the line, “ST.setTimeout(100);” in the void setup() section immediately after the line, “menuSetup();”. RufusDufus sketch however, as he indicated, would need to be rewritten to use packetized serial instead of simple serial in order to set timeouts.

@BlazingH thanks for the time you spend to answer on this. Only one remark of the acceleration issue: the issue does not happen when the motors are accelerating, it happened after leaving an AC race coming back to the AC menu. You are 100% right on the interferences but in my case and opinion the issue is somewhere else. NTL I will optimize as much as I can by following your suggestions.

Code:

    menuSetup(); //Initialize menu structure
    ST.setTimeout(100); //Set the timeout in case of malfunction
    ST.motor(1, 0);
    ST.motor(2, 0);
    disable = 1;

PS; What is "better": Setting the value using Describe (stored on Sabertooth) or using the sketch code...?

PS2: to avoid any more bumping into the wall I secured the motors by using an additional mushroom button.

Hi @Pit, you got the code right!
I've never set a timeout using Describe but the only documentation I've seen says that the setting won't persist thru a power cycle so I don't think it makes a difference what method you use to set it. Therefore, its better to let the sketch do it automatically verses doing it manually with Describe each time you power your arduino down and then up again.

PS. Thank Goodness for mushrooms!

I thought that was your issue because of this you said in a different thread.

It shouldn't be accelerating after a malfunction unless the last command received by the sabertooth told it to do so. And do you have issues when you leave (exit) other game titles? You know, where most simtools plugins start and stop when the game starts and stops, AC's plugin starts and stops each time you enter and exit a race.

I play only AC

Hello !

Back from holydays, without internet access, even with a cell-phone
When you leave, the plugin should send the end sequence which should result in putting the rig to the standby values you have set. I'll double-check the code and let you know. What is the standby you have set ?

Hi standby set is standard (from memory I think 512?) BTW every time when I restart the rig (the Ard is always connected to the PC) the settings of Motor 2 changed...when I am at home ( Im in Germany at the moment) I will report more.

The shutdown- output setting should be as follow:

XECCC should set the motors to their standby value. You can also force standby by wiring pin 52 to ground.

XECCC is set correctly (10ms). I will try out the GND pin.

Hi there !
I found out why sometims the values are not saved to the EEPROM. There is a safeguard to avoid EEPROM burning. There is no EEPROM writes in loops, so no worries with that, especially as the EEPROM gets written only if the value changed (read before write)
You have to disable the protection by commenting the following line in the file EEPROMex.cpp
//#define _EEPROMEX_DEBUG // Enables logging of maximum of writes and out-of-memory
Sorry for not spotting that earlier.