MobiFlight Community Support

I have several stepper motors driving the backup instruments in my A320. I am trying to get the auto home function working but have run into problems. Each stepper has a micro switch that sends 5v high at Zero to the Mega pin. The steppers keep going around and do not stop. I have noticed that when I allocate a pin to this function in Mobiflight on the Mega, the pin goes high 5v, I would have thought that the Mega pin should receive a high signal from the micro switch and not be 5v high? Please help.
Mark

I not Build this Autozero System.... Also Stephan not test this as i know.

But technical this can be checked with a Multimeter scanner.

Whatever..... If It follow the Logic, Mobiflight use in all other Spots then you must wire the used Pin to your switch.... and then the other side to GRD. ( Not to 5V)

Every Input Switch work so.... A Simple Input Button also is wired PIN-Switch-GRD .... The 5V is not needed for Inputs.
In case the Zero Function is technical also just a Input switch then i would say 99% the solution is simply to connect it to GRD.

Perfect, yes I needed to switch GND not 5v+, all working now thanks for your help

Nice
Your welcome !

Hello,

how is the auto calibration implemented?

I mean there are two cases at start of the auto-calibration:

1. Case Sensor is high
2. Case Sensor is low

So if the Sensor is low at beginning then it is easy to drive stepper until is high.
But if sensor is high at beginning (means stepper is on sensor) then you have drive stepper until sensor is low and then drive in opposite direction until sensor is high again.

I mean it is not working so?

I have figured out if the sensor is high at beginning means stepper have reached endstep - then the stepper is not drive off the sensor and drive again to the sensor at start.
This make a very unaccurate auto calibration - or i'm wrong and my test are also wrong?

I not know the code....
But if i just think about it then its no difference ( point of view to accurate calibration) .

I understand it so....
At Startup the Stepper recive a "turn endless into one direction" command. And then a signal on the Sensor Pin tell the Stepper he reach the Point.
Maybe there is no "wait for signal and turn endless" logic...
Maybe its more difficult and it say "make One Step to the left.... Check if Sensor have a signal... If YES Stop.... In No go back to start and make again one step to the left".

So the Only difference if it act from Low to High or From High to Low.... Or maybe both ( it act if there is a signal Change whatever in witch direction) .... All will do the same.
The only thing can be that it make a "unneeded" 360° Turn at beginning.....
But thats no mater.

If i missunderstand your question.... Please correct me.

Hello,

so to prevent misunderstanding - like CNC-Machines do it... like my explanation above.

So what i mean is:

1. Case Sensor is reached (Call it High maybe the logic is High-Active) before any movement of the stepper.
2. Sensor is not reached maybe in some other point of the stepper

In the first case the stepper will not make any step if the sensor is always reached... so you can not make auto-calibration.

Hope you understand the problem... and a 360 degree turn first do not prevent this - because you can not be sure the stepper is not on the endstop...

If you have a Stepper and the Endswitch is on 12 o'clock... If the stepper is on 1 o'clock or on 11o'clock is not a problem to find the endstop on 12 o'clock...
But if the stepper is on 12 o'clock >> PROBLEM.

So for this CNC-Machines first check if endstop is High - if so then drive out of sensor until is low then drive opposite back to sensor until is high again.

I will look into the code to check this out... on my test the stepper is not moving if sensor is high - so no auto-calibration is possible.

I think we talk about 2 different things.... Pretty sure i also missunderstand your first posting !


Your right... The Sensor must work in correct way that is expect by Mobiflight. If its inverted to the logic it will not work !

As i know from Sebastian the Sensor is technical like a button for Mobiflight..... A Button is set to a Pin and to GRD.... Means it "close" a circuit form a (i think high) Pin to GRD.

That means to me.... The Sensor ( Whatever touch, magnetic, light, laser ) must CLOSE a circuit between In and Out in the moment when the Gauge needle is on Zero Point.
If its not on Zero the "Sensor" is like a unpressed button and is "open" .... means the In and Out have no connection .

So.... The Sensor must be NO "normaly Open" ... If you use a sensor that is NC "normaly Close" this will not work i think.

You can simply confirm this by a testing ( i´m not on my flight Sim PC.... And i also not have a Sensor based Motor.... Would be cool if you can do)
Setup a Stepper and enable the Sensor Mode.... Use a Pin e.g. Pin 10 for the Sensor.
Then wire a Button to Pin 10 and GRD. If you not have a Button simply use a Jumper wire. Then Start Mobiflight and check what the stepper do..... In my theory it will turn endless.
Then press the Button OR if you use a Wire connect the other end into GRD by hand...... Simply close a line from Pin to GRD.

If i´m right the Stepper stop and use this point as Zero .

********

About your explaned Situation.... Here i not understand the Problem already again.
If the Stepper is at startup already in the Zero Point ( so the Pin /Sensor is active this moment ) .... Why should the motor turn and then go back ?
A High Pin means the Gauge needle is already in the perfect position.... If it is a little left or right the sensor is no longer active and the motor would make a calibration.

So please tell/explane me what problem you see here.... Why do you like a rule that a clibration Run MUST be done if we still know it is already in Zero Point ?

********

Please confirm if i now understand your problem correctly.... And also report experience if you do this testing !

Hello,

i see you have not understand the Problem - you think to abstract - think in real mechanic.
A endstop like a switch or sensor have not the ideal switch-point - it can be a range.. so if you use a infrared-sensor for example then you have a beginn of detect and a detect-zone itself.
Depending from the sensor you can have many milimeters of range in this detect-zone.
And if the Stepper is on start on the sensor - you don't know in which space of the detec-range of the sensor it is.
For this the CNC-Machines and all other industrial autmotoive steppers machines make a different AutoZero - called Homing. Most of the 3D-Printer make it also wrong... But it is not the problem if you make one print - but it is a problem if you power off and on the machines during printing - then the homing is different if the machine is on an endstop on startup if you want to make your halfprint finish...

So for prevent this you drive to endstop - detect the endstop - then drive out of endstop - then drive to endstop again.
In this precedure you can on Endstop in any detect-range of the sensor and in this case the stepper drive out of detect-range and it find in any situation the begining of the detect-range of the sensor.

I have checked the sources and it is not implemented - i have implemented this yesterday evening and have send to sebastian the changes of the arduino-sources.

For me is important because i use infrared-optical sensor to find Zeropoint of the Gaugestepper and dependig from the thickness of the needle (about 3mm) i have different zeropoints - depending from the needle it is on the sensor - is it in the middle of the needle like 1,5mm? Or is it on the end of the needle like 3mm? Or in the beginning of the needle like 0,5mm? You see in all this cases the actually autozero-code set this point to zero. And then you have inaccurate needle Positions on the instruments.

Of course in most of the cases the stepper is out of the detect-range - but in the case is it on the sensor-detect-range - then wrong accuracy occur. So i think prevent this is good idea.

Here a video to show the correct sensor-detect-range finding.
I have make a big needle so the sensor have now a detect range about 12mm - so for showing the problem.
With old auto-zero code any of the needle position over the sensor in range of 12mm - all is set Zero.

With the new code it find the beginning of the needle. So it is correct i mean.

Video-Link:http://www.nighteagle.de/AutoReset.mp4

Hi again

Thanks for detailed informations.

My thoughts here was pretty different.
Just to show "how" i think i will shortly explane.

1. Exactness....
A 3D Printer or a CNC need perfect Calibration... like you explane with a multi season project.
But a Gauge ??? Sure in your extreme Example of the Video we got a problem.... But with a normal gauge we would have maybe a missposition of 2-4 Degrees.
Lets say you build a Altimeter... 360° represent 1000 ft. 1° represent ~3ft. So our issue range would be 6-12 ft . Do we realy care about this ?
Specialy if the Problem only occure in as you say rare situations.

2. Detection with a "big needle" . I not build a system like this already.... But i never think about to build the "sensor" in the front and use the Pointer needle for this.
All ideas and prototyps i see till now build the calibration system "inside" of the gauge.
Means the shaft of the Motor end in the Gauge needle..... But between the Gauge front plate and the motor there are lets say 5cm empty place. And THERE is a second element on the shaft.
For example a second small needle that touch a mechanic sensor.... a Needle that block a laser for a short moment.... Or a solid Disk that have a small hole on one point whre light is shine thorugh and controll a photcell e.g.

************

Basicly.... I´m happy you find a way. and i´m thankfull your a programmer and also support Sebastian this system.
Lets wait for his awnser.

Hello,

yes you are right - a gauge is not so extremly accurate as a cnc - i'am in your boat.
And yes - you are right with the second needle - i make it also so for detection on a gauge.

But i want also use stepper for other things like trimmwheel and so on... i will prevent further problems so i have solved this problem.
After a correct calibration i need also an offset to move the needle on the "0" on the display of the gauge - then the endstop-sensor must not be the same point as the "0" or Neutralposition on the Instrument.

And if i see a needle they show me 1-2 Degree more or less then the "0" it depends from the length of the needle to have it maybe on 2 or 5 on the Display.

But each can build so accurate they want.

I have found some other things too - the missing Offset after Autozero then a acceleration and speed for each stepper - not a hardcoded one for all.
If i use different stepper and different needles of course - i have to change this values for smoothing and accurrate moving for each isntrument/each stepper.

Then the big problem some people have the idea to connect a stepper-driver with two pins (DIR and STEP) on the arduino with Mobiflight Stepper Modul if only accepted 4Wire stepper-Amplifier. So for un derstanding a STEPPER-DRIVER is not a STEPPER-AMPLIFIER like some people use with the UN2003 and the 28BYJ.

I read some use the easy-driver (is a STEPPER-DRIVER with two Pins) and the connect it wrong to a 4Wire Output on Mobilfight. They tell it works if you double the pins but mobiflight not allowed to double pins. It looks only double - if you upload it the use the old pin-numbers. So in the real-world the two pins are connected to the easy-driver totally wrong and the other pins are not connected.

I have checked the firmware - they cannot use the same pins... but it works some people say... i have tst it out and i can say - yes it looks like it works.. but this is not correct.
So for understanding a stepper-driver with two pins they are two important things.
DIR is a Pin that can be Low or High and set clockwise or counterclockwise. STEP is the steps to move itself. So if u use a stepper-driver on the 4 wire pins of mobiflight (yes they dont have DIR) then you can see the stepper is moving - so WHY? Yes i can explain it easily - it moves but with lower speed as it should and missing steps. Then each of the 4Wire are stepping... so it means the DIR-Pin of the stepper-driver also go low and high every step. So depending from the step-frequency the stepper-driver set the stepper back and forward because the DIR-Pin now is high and low... that is totally senseless and nonsense.

But so far the frequency are always the same and people don't see the problem.

Later i found problems in the forum from people talking have problems with speed of the stepper and so on... this all problems because of wron using stepper-driver on stepper-amplifier-outputs.

If i use a gauge-stepper with easy-driver on mobiflight in the wrong way - then i can become a stutter moving and extremly slow speed with less torque - so around 4 seconds for one revolution.

If i change the arduino-firmware to working with 2Wire Stppper-Driver (Yes it is possible easily - Library Sebastian use can do this) then i have smooth moving in under one second with a higher torque.

So long text and short sense - if we make it correct - then we can prevent problems in the future - thats my 50 cent.

I have implementet correct way to drive gauge-stepper like the X27 with the correct driver for it (- not the easy-driver because is not for gauge-stepper -) now i have to implement in the GUI so everybody can use it - but it takes a little bit because some questions to Sebastion unaswered now.

But in this way i can say it is very easy to use X27 Stepper with the correct Driver like the X1201728SG with the mobiflight arduino-firmware. Have some Video again to show how speedy is a X65 Stepper (Double Torque for bigger needles like the X27)

http://www.nighteagle.de/X65Rotation.mp4

I´m realy impressed about your motivation. and i hope you not feel attacked in case i not jump in the air and i was still a little sceptic.

Your Idea is pretty good.... But as i see its maybe get in conflict with Sebastians main policy for Mobiflight.
So i high recommend to you to talk to him. Not only via Emails.... The best way to get a new feature is talking ( e.g. via Discord) and persuade him from your Project.

In the past Mobiflight got a verry simple main rule.... We only implement things, if it´not possible to build a element without that feature.

So for example.... The old Matrix Thematic. Lots of people want it. But Sebastian strickly is against it as i know.... Simple argument. If You need 200 LED Outputs then it is still possible by using 5 Megas. Its no argument that you can build it with 1-2 Megas by Matrix.... Cause Number of Megas are not limmited. So we not need this new feature to get the same result ( expect save 10$ for the additional Megas)

Same with Displays.... Some people request for alternates to Max7219..... In case they have Premade Tubes in correct size , Collor and number of Diggits with a other driver.
But also here Sebastian said.... Each Display Variation can be done with Max7219.... May you need to resolder and spent 100 hours to find a perfect Display in a China Shop..... But it exist... It is possible... So we not need something new.

Another big thematic is the most rudimentary and easy GUI as posible.
If we not allow to change the Speed of a Stepper then your right. Maybe some Projects get in trouble and need to build a external gear to handle this. BUT 95% of Users are happy with the hardcoded Speed. Sebastian simply say these 95% get confused about a new Setting field.... The user must learn this new feature.... We Supoorters must explane it.... And finaly only a small number of people need it but a high number of user must handle a new system they not need/want.


*******
BUT

He also broke with his policy in the past....
For example the Analog Pin Support. We always say... a Mega allow 52 Pins. If a user need more he should use a second Mega.
But (whatever why) Sebastian get conviced that this is usefull and also allow the usage of the Analog Pins some months ago.

I think his master argument is always time. He can not work on Mobiflight verry often in case of Job and Family... So he choose for the most important things and must ignore other ideas ( whatever they are usefull).

So.... If you like to support and give him a working code he just need to release.... Then maybe we see this feature.

Hello,

thanks for this thoughts...

So this is like we build a car with 4 wheels maked from wood and powered with an old steam-engine. We can drive this car and all people are fine about this.
We don't need a car with is more modern technique - because the old steam-engine powered wood-car can do the job.
This is the opposite to progress in time - but i think you right - Sebastian have not so much time.