Page 1 of 1

New Oerhead, with servo BUG

Posted: Fri Jan 02, 2015 11:49 am
by reggie
I just received a new Overhead panel from OC on December 2014.
When I've tried to test it, I remark all gauges needles was at their maximum.
During the time I was analysing an testing the script v3, I burned 3 servos.

I don't know if OC change the way they are building their gauges, but I had to change all the servo'script.
I had to remove all reverse needle script and recalibrate all gauges.

Has I burned 3 servos, I can not confirm for engines start and manual valve servo.
SO BE CAREFUL IF YOU USE A NEW OH PANEL.

I'm suggesting A BIG WARNING in OC4BA instructions.

Thank you

Reggie CYQB
Running under win7 and FSX

Re: New Oerhead, with servo BUG

Posted: Fri Jan 02, 2015 9:48 pm
by mvr1918
Hi,

Sorry to hear that you have burned your Servos.

Normally you do not burn servos because they have a wrong direction movement in the scripts.
If they are manually turned in any position but 0 they will be destroyed.

Burning servos attached to Opencockpits Servo card is not an unknown problem. I also burned several servos when I made my scripts and did the testing.

The OVH module is not a P&P module as MCP, EFIS..

It is constructed by use of standard IOCARDS like Expansion, Master and Servo cards and different connections can occur between different assembled units.

I will put a warning in the OC4BA description based on the same wordings as in the Servo Card manual.

Re: New Oerhead, with servo BUG

Posted: Sat Jan 03, 2015 11:34 am
by reggie
Thank you Roar for you attention.
If you remark, the 3 servos affected is those one who are not full course.

My opinion is OC should have standard procedure when they build a piece of Equipment.
And a least let you know when they made modification.

You certainly know that we bought OC equipment because of you and they should treat you as a partner.

Thank you again

Reggie CYQB

Re: New Oerhead, with servo BUG

Posted: Sat Jan 03, 2015 1:05 pm
by mvr1918
HI,

Which ones where the servos you burned? These ones?
Var 0237, name SERVO_CabAlt, Link USB_SERVOS, Device 36, Output 4, PosL 187, PosC 324, PosR 1023, Type 1
Var 0244, name SERVO_PresDiff, Link USB_SERVOS, Device 36, Output 3, PosL 192, PosC 511, PosR 1023, Type 1
Var 0245, name SERVO_PressL, Link USB_SERVOS, Device 37, Output 3, PosL 180, PosC 537, PosR 1023, Type 1


Looking into this, I believe the wiring is the same , but that the mounting of position of the servo arm have been different.


As I said earlier I also burned some servos, then sent in a claim and got new ones for free.

Re: New Oerhead, with servo BUG

Posted: Sat Jan 03, 2015 3:52 pm
by reggie
There are

Var 0217, name ENG1_Servo, Link USB_SERVOS, Device 36, Output 6, PosL 512, PosC 512, PosR 1023 // OVH_ServoCard
Var 0224, name ENG2_Servo, Link USB_SERVOS, Device 37, Output 5, PosL 512, PosC 512, PosR 1023 // OVH_ServoCard2
Var 0250, name SERVO_OUTFLOW, Link USB_SERVOS, Device 37, Output 4, PosL 1, PosC 511, PosR 1023, Type 1

I will probably let them know, that, but in other hand I understand that they are not responsible for the script.
And in my point of you, you are not responsible either.

I 'have already order some servo over the net and that's not an expensive parts.

In my understanding OC sold a lot of equipment because of your work and they should consider your work part of the quality control process.
And put more attention to their manufacturing and keep you involve in de development process.

This is my humble point of view.

Thank again Roar

Ps By the way I have also order a OC AFT Overhead, I do not start yet to program it, so do you have any base script available

Re: New Oerhead, with servo BUG

Posted: Sat Jan 03, 2015 11:10 pm
by mvr1918
Hi,

The Servos that you burned were the same as I burned during my scripting and testing, I now remember. What I learnt from that, was to NEVER turn the servo manually if not in ZERO position when power was on.

No, I haven't yet decided to to get the AFT OVH and therefore has not scripted this unit.

Doing the script for the OVH was a nightmare. The main reason was that the PMDG SDK variable status do not reflect the actual on/off state you see on the virtual OVH in all different electrical states. I believe I defined it to be 16 states all together.
So I had to develop my own state logic to get things OK. I guess that you can encounter some of these issues when doing the script for the AFT OVH. If this is the case you should use my logic in the OVH script also for the AFT OVH.
But, I do not know for sure that it is necessary as the module is much simpler than the FWD OVH.
PMDG is aware of this and hopefully they will correct his in an upcoming SDK SP2( if it is ever released)

In the beginning I sent my script to OC for test/verification, but I think they never had time to really look into it. Yeah, I know they have sold a LOT of modules to be used with PMDG and OC4BA.