NGX Trimwheel

[DanW]

I'm controlling the NGX trim wheel with my Saitek trim wheel via lua script. This is working, the trim wheel moves etc.

However when using it for a little while probably when I trim alot at once then FSUIPC crashes FSX.

It may be when I get to the end of the trim wheel actually.

Am I doing something wrong in my script or is it an FSUIPC issue?

FSUIPC version: 4.843

Details of the error and log file: https://dl.dropbox.c...68/LuaCrash.zip

My script is in the Auto.ProfileName section, and also in the LuaValue on the Trim axis assignment as recommended in another thread.

This is the current script, note I have to repeat the controls alot because otherwise the wheel hardly moves at all and I run out of physical wheel before I run out of virtual wheel.

function checkvalue(val)
   if prev ~= nil then
		  if val > prev then
		ipc.control(65607)
		ipc.sleep(50)
		ipc.control(65607)
		ipc.sleep(50)
		ipc.control(65607)
		ipc.sleep(50)
		ipc.control(65607)
		ipc.sleep(50)
		ipc.control(65607)
		ipc.sleep(50)
		ipc.control(65607)
		ipc.sleep(50)
		ipc.control(65607)
		ipc.sleep(50)
		ipc.control(65607)
		ipc.sleep(50)
		ipc.control(65607)
		ipc.sleep(50)
		ipc.control(65607)
		ipc.sleep(50)
		ipc.control(65607)
		ipc.sleep(50)
		ipc.control(65607)
		ipc.sleep(50)
		ipc.control(65607)
		ipc.sleep(50)
		ipc.control(65607)
elseif val < prev then
		ipc.control(65615)
		ipc.sleep(50)
		ipc.control(65615)
		ipc.sleep(50)
		ipc.control(65615)
		ipc.sleep(50)
		ipc.control(65615)
		ipc.sleep(50)
		ipc.control(65615)
		ipc.sleep(50)
		ipc.control(65615)
		ipc.sleep(50)
		ipc.control(65615)
		ipc.sleep(50)
		ipc.control(65615)
		ipc.sleep(50)
		ipc.control(65615)
		ipc.sleep(50)
		ipc.control(65615)
		ipc.sleep(50)
		ipc.control(65615)
		ipc.sleep(50)
		ipc.control(65615)
		ipc.sleep(50)
		ipc.control(65615)
		ipc.sleep(50)
		ipc.control(65615)
		  end
   end
   prev = val
end

event.param("checkvalue")

EDIT: Here is the final NGX Trim scripts for any other users that want to do the same thing:

https://dl.dropbox.com/u/29331868/NGX_Trim.zip

[Pete Dowson]

I'm controlling the NGX trim wheel with my Saitek trim wheel via lua script. This is working, the trim wheel moves etc.

Why all the "sleeps" between controls? That in itself means you need more controls, because each change to the parameter (axis value) is taking nearly a whole second to process in the Lua before the next value can be seen.

However when using it for a little while probably when I trim alot at once then FSUIPC crashes FSX.

It may be when I get to the end of the trim wheel actually.

When you get to the end of the axis the parameter won't change anymore, so the Lua won't be executing.

Am I doing something wrong in my script or is it an FSUIPC issue?

FSUIPC version: 4.843

Well, that's the first thing that is wrong. 4.843 is out of date. 4.853 is the minimum supported version, and the current version is 4.857. Please ALWAYS make sure you are using the latest version before submitting a question or report. You'll need to re-test with the current version, please. Even the error details you took a picture of cannot be applied to the currently supported version.

This is the current script, note I have to repeat the controls alot because otherwise the wheel hardly moves at all and I run out of physical wheel before I run out of virtual wheel.

Yes, but most of the trim wheel axis changes will be missed because it is only using one change every second or thereabouts (all the sleeps added up). The way to get more response is to reduce the Delta value in the axis assignment - I see you've left it at its default of 256, so all changes of less than 256 will be ignored. Try 1 to catch every change, and only have one control in your Lua not many. See how that works, then adjust the Delta till the ranges match up.

If you still get a crash at all, I will need the crash details again (but it is more efficient to get them from the Windows error log. You can copy and paste them from there into a message rather than taking a picture).

Regards

Pete

[DanW]

Hi Pete,

Sorry it didn't seem that long since I updated, you certainly provide better support and updates than many other vendors. I installed your FSUIPC update and now I'm at 4.857

Thanks for the tip on the delta, I had it lowered on my other assignments but forgot it here.

Now I've tried it with a delta of 1, and removed the sleeps. The sleeps where an attempt to get around the script not doing exactly what I wanted, it doesn't seem to move the trim very far so I thought it might need to wait until the first part had done or it might have been ignoring duplicate commands. But it makes no difference so I've removed them.

On the error, it happened after the new version too but only once, I think I may have still had the sleeps in:

Faulting application name: fsx.exe, version: 10.0.61637.0, time stamp: 0x46fadb14
Faulting module name: FSUIPC4.dll, version: 4.8.5.7, time stamp: 0x50604b89
Exception code: 0xc0000005
Fault offset: 0x000435cd
Faulting process id: 0x177c
Faulting application start time: 0x01cd9ab53e0d10d5
Faulting application path: S:\fsx\fsx.exe
Faulting module path: S:\fsx\Modules\FSUIPC4.dll
Report Id: a91027ce-06ab-11e2-875f-bcaec591772d

However I cannot reproduce the crash anymore, it only happened once. I can't remember if I removed the sleeps before or after the crash, but I'll find out eventually if it happens again.

I get hardly any movement out of the trim, which is why I need to add so many ipc.control. I can move through my whole trimwheel axis range, and only get 5% out of the NGX trim like this. Using several entries doesn't help. The wheel still moves soo slow. Do you have any ideas on how I can make the trim move further? I have 15 ipc.controls in a row and it seems to do the same movement as having only one entry. Could there be a problem of the script still executing when the trim wheel moves and triggers the script again?

I noticed tapping the trim button in the NGX doesn't move it very far, but holding it down does.

Is there a way I can tell the script to hold down the ipc.control for 1 whole second or a certain amount of milliseconds?

Or a push, then sleep, then release?

many thanks

[Graham Pollitt]

I installed your FSUIPC update and now I'm at 4.853

Why don't you just start with 4.857 as there are other fixes inbetween those versions?

[DanW]

Why don't you just start with 4.857 as there are other fixes inbetween those versions?

Sorry I meant to say 4.857 :oops:

Slip of the finger due to last version number..

[Andydigital]

He is using 4.587 look at the error log above ;)

Edit: Ninja'd by Dan

[Pete Dowson]

On the error, it happened after the new version too but only once, I think I may have still had the sleeps in

Hmm. Shouldn't occur in any case, sleeps or no. I'll see if I can reproduce it here. Thanks for the error log data, that'll be useful.

I get hardly any movement out of the trim, which is why I need to add so many ipc.control. I can move through my whole trimwheel axis range, and only get 5% out of the NGX trim like this.

These are normal trim increment and trim decrement controls. It's such a shame you can't simply assign it as an axis, as intended. I think you said that was because you like to use what would be the electric trim adjustment on your yoke, right? And the trim wheel position then wouldn't match?

Using several entries doesn't help.

Strange, that. Each one should move it a tad -- same as a single tap on the 1 or 7 numpad keys.

The wheel still moves soo slow. Do you have any ideas on how I can make the trim move further? I have 15 ipc.controls in a row and it seems to do the same movement as having only one entry. Could there be a problem of the script still executing when the trim wheel moves and triggers the script again?

No. The event system only calls the function when the Lua thread is idle (i.e. after the previous call has exited). The whole function is executed every time the event occurs. BUT there is no event queue -- all the PARAM changes which occur whilst the previous change is being dealt with will be collapsed into just the one change. So a Delta of 1 mught have the same effect as a delta of 32 or 64 or whatever, depending on lots of factors including how fast the wheel is turned. You would probably get more movement from slow turning than fast turning.

I noticed tapping the trim button in the NGX doesn't move it very far, but holding it down does.

That's the FS "control acceleration" operating. It does that for things like radio frequencies, headings, altitudes, all types of adjustments -- but only on the keyboard. Theoretically a pair of identical TrimUps and Trimdowns, with no other control between them, should do the same. In that respect it is self-defeating inserting sleeps.

Is there a way I can tell the script to hold down the ipc.control for 1 whole second or a certain amount of milliseconds?

Or a push, then sleep, then release?

Controls don't work like that. They are neither "held" nor "released", they are simply events.

There is another alternative, but I don't know if it will work with the aircraft you are using. That is doing the increment / decrement yourself, instead of relying on the inc/dec controls. This is actually one of the detailed examples in the User Guide -- search for "Offset Increment/Decrement Controls". You can do the same thing it is describing in the Lua program -- read the offset by

trim = ipc.readSW(0x0BC0)
[/CODE]

Then adjust it, possibly by the difference in your previous and current PARAM value. For example:

[CODE]
trim = trim + val - prev
if trim < -16384 then trim = -16384
elseif trim > 16383 then trim = 16383 end
ipc.writeSW(0x0BC0, trim)
[/CODE]

You don't need to check if the value is going up or down this way.

Another way if to use some fixed amount, arrived at experimentally. But I think the above is most flexible.

Regards

Pete

[Pete Dowson]

Hmm. Shouldn't occur in any case, sleeps or no. I'll see if I can reproduce it here. Thanks for the error log data, that'll be useful.

I've managed to get a similar crash, but it took a while, ad it seems to happen more if Lua logging is enabled. I've tracked it down very very deep into the Lua interpreter logic. It looks like there's a number of places in the original Lua code where things are used without checks. with threads coming and going I find a lot more checks are needed.

Anyway, I've added checks in three places which I think are relevant, and in version 4.858, which i'll release later today or maybe tomorrow, I can't get it to crash at all.

BTW I tested with the idea I had in my last message, where you are using the difference in the parameter values as an increment / decrement, and I think you need to do a few things slightly differently:

1. If, like my test axis (not a wheel), you need to reverse the trim action to match wheel-for-wheel, you need to change

trim = trim + val - prev[/CODE]

[size=4][font=arial,helvetica,sans-serif]to[/font][/size]

[size=4][font=arial,helvetica,sans-serif]

[CODE]trim = trim + prev - val[/CODE]

2. You might want to reduce the effect somewhat. if so, just divide the difference byt some factor, e.g.[/font][/size]

[CODE]trim = trim + ((prev - val) / 2)[/CODE]

[size=4][font=arial,helvetica,sans-serif]3. With a Delta of 1 your trim is subject to any jitter on the wheel axis. Set it instead to the minimum change you can see in the axis inputs x 2.[/font][/size]

[size=4][font=arial,helvetica,sans-serif]4. You'll probably want a button you can push to centre the trim, for initial use or after loading a flight with the trim non-centred. Assign the button to [b]Axis elev trim set[/b] with parameter 0.[/font][/size]

[size=4][font=arial,helvetica,sans-serif]Pete[/font][/size]

[DanW]

Hi Pete,

Your memory is good, I did intend to use that script for all planes to avoid the jump when first using the wheel after disconnect Autopilot. But assigning it as a normal axis is easier you're right, reaching the end of axis was a pain as well as the scripting. So I did away with that and just reverted to assigning as a normal axis - and held the yoke when activating the trim.

Normal axis works fine for most aircraft - except the NGX, PMDG have done something special with the trim. Therefore it doesn't support AXIS trim. Basically if you have an axis assigned to trim, it will only move the trim in one direction. Roll the trim forward, it goes forward, roll the trim back, it goes further some more! PMDG's answer to queries on this is that it's more realistic to use only the buttons on the yoke which may be true I don't know. I like to keep up the physical movements I use when flying GA aircraft so my preference is to use a trim wheel in all planes, and I just like the feel of that.

Thanks for the script help I think I'm happy with this now. I added a few things to get round some problems:

1. The trim was backwards so I inverted the axis

2. ipc.control was needed as well to "activate" the change - writing to that offset stored the value but didn't update the elevator or wheel until hitting the button or calling ipc.control

3. Negative trims were achieved and bypassing NGX limits. The 737 has different trim limits based upon flap settings but luckily PMDG use the value of 0 in the offset for the limit. So even if the forward Trim limit changes to 3.95 with flaps down, internally that is 0. This is probably why trim was only going one way before, I think they may only use one side of the axis.

Here's the final script if anyone else wants to do the same thing:

function checkvalue(val)
   trim = ipc.readSW(0x0BC0)
   --flaps = ipc.readSW(0x0BDC) --Not needed as NGX sets 0 trim dynamically based on flaps

   if prev ~= nil then
    trim = trim + ((val - prev)*2) --increase movement

    -- Prevent going past end of trim, NGX trim is one side only
    if trim < 0 then trim = 0
    elseif trim > 16383 then trim = 16383 end

    ipc.writeSW(0x0BC0, trim)

    -- Send an trim increment control to force trim update
    if val > prev then ipc.control(65615)
    else ipc.control(65607) end

   end
   prev = val
end

event.param("checkvalue")

One thing I have to do is try and have my trim centred before loading the flight, but otherwise this solution works well thanks!

Cheers

[DanW]

I've managed to get a similar crash, but it took a while, ad it seems to happen more if Lua logging is enabled. I've tracked it down very very deep into the Lua interpreter logic. It looks like there's a number of places in the original Lua code where things are used without checks. with threads coming and going I find a lot more checks are needed.

Anyway, I've added checks in three places which I think are relevant, and in version 4.858, which i'll release later today or maybe tomorrow, I can't get it to crash at all.

BTW I tested with the idea I had in my last message, where you are using the difference in the parameter values as an increment / decrement, and I think you need to do a few things slightly differently:

1. If, like my test axis (not a wheel), you need to reverse the trim action to match wheel-for-wheel, you need to change

trim = trim + val - prev[/CODE]

[size=4][font=arial,helvetica,sans-serif]to[/font][/size]

[size=4][font=arial,helvetica,sans-serif]

[CODE]trim = trim + prev - val[/CODE]

2. You might want to reduce the effect somewhat. if so, just divide the difference byt some factor, e.g.[/font][/size]

[CODE]trim = trim + ((prev - val) / 2)[/CODE]

[size=4][font=arial,helvetica,sans-serif]3. With a Delta of 1 your trim is subject to any jitter on the wheel axis. Set it instead to the minimum change you can see in the axis inputs x 2.[/font][/size]

[size=4][font=arial,helvetica,sans-serif]4. You'll probably want a button you can push to centre the trim, for initial use or after loading a flight with the trim non-centred. Assign the button to [b]Axis elev trim set[/b] with parameter 0.[/font][/size]

[size=4][font=arial,helvetica,sans-serif]Pete[/font][/size]

Sorry I wrote that last post before checking for new posts, the window was open in the background while I was testing.

It's funny you are reducing the effect and I am increasing it :)

I think it depends on the sensitivity of the trim wheel. Saitek Cessna wheel has 9 full rotations with a large diameter wheel, so it's quite fine. Increasing the effect means less likely to hit the end of the axis as well as I don't need to go as far.

[size=4][font=arial,helvetica,sans-serif][b]Axis elev trim set[/b] - just gave it a try, unfortunately it's not working for me with parameter 0. Maybe the NGX doesn't like it or they are setting the FSX trim to a value remembered in their code.[/font][/size]

Thanks for the fix for lua logging, I haven't had any crashes after that one today but good to prevent any others.

Cheers

[Pete Dowson]

It's funny you are reducing the effect and I am increasing it :)

I think it depends on the sensitivity of the trim wheel.

Yes, exactly. I was using a lever on a Saitek quadrant for testing. It appears to have a fairly low resolution -- a Delta of about 128, so there aren't that many values between full trim up and full down. Your wheel is less sensitive in this regard (or, rather, more precise -- probably a better way of describing it -- "sensitivity" is ambiguous because it depends on whether you are considering cause or effect).

Axis elev trim set - just gave it a try, unfortunately it's not working for me with parameter 0. Maybe the NGX doesn't like it or they are setting the FSX trim to a value remembered in their code.

If they are only using half the trim range, maybe the parameter needs to be 8192 or -8192, depending which half? Or try the other control, "elevator trim set". Maybe you have to send a single trim up or down command too, as you found was needed in the Lua plg-in? You could even have a small macro for that -- or even replace the Axis setting control with an Offset Word Set control for the trim offset and whichever is the correct parameter for centred trim.

Regards

Pete

[DanW]

Got it working with a Lua to reset at value 0 followed by ipc.control.

0 is the forward most position and close to where takeoff trim is as well, but that's fine I can just set my trim wheel near the top before pushing the button.

I just have to remember not to push that button in flight, or I'll be pointing at the ground!

Cheers and thanks for the Lua help

[Gypsy Baron]

Got it working with a Lua to reset at value 0 followed by ipc.control.

0 is the forward most position and close to where takeoff trim is as well, but that's fine I can just set my trim wheel near the top before pushing the button.

I just have to remember not to push that button in flight, or I'll be pointing at the ground!

Cheers and thanks for the Lua help

FYI, there is an offset (0x0366) that will tell you if the sim is on the ground or not. You could test this to prevent any unwanted actions

while in flight. On the ground = 1.

Paul

[DanW]

Good idea Paul

[Pete Dowson]

Thanks for the fix for lua logging, I haven't had any crashes after that one today but good to prevent any others.

Actually, it wasn't a bug in the logging area -- the logging actions merely exacerbated it. The problem turned out to be that LuaValue controls were immediately changing the Lua parameter "ipcPARAM" on the plug-in's stack whilst that plug-in was runnnig, without any regard to what sort of things might also be going on in that thread and on that stack!

A real silly mistake, and lucky not to have been causing more widespread problems!

Fixed now in FSUIPC 4.858 and 3.999x, both available in the Download Links subforum. The ipcPARAM value is now only set when an event occurs and its function is called, or during an ipc.sleep (where it cannot do any harm).

Thanks for the report which led to this fix!

Regards

Pete

[DanW]

Great! I'll grab that version

[DanW]

At user's request, I've attached the final scripts to the first post for them to use.

[wichi1616]

I cant donwload the file, please reupload it. Regards

[monetel]

The files are offline, please anyone have to publish them, regards