aua668 Posted June 10, 2012 Report Share Posted June 10, 2012 Hi, There is a difference in the function gfd.SetLight between using it with the GFT8 and the GFRP48: While the setting and clearing of single lights independetly works on the GFT8, it shows a different behaviour on the GFRP48. There setting one light clears all the other lights. The gfd.SetLights function works the same for both modules. I don't know, if this is by design or if this is a bug. Maybe you can look in the code. I use FSX and Win 7 64 bit and the latest FSUIPC and LUA package. Btw: It would be fine to have a function for reading the LED status. Rgds Reinhard Link to comment Share on other sites More sharing options...
Pete Dowson Posted June 11, 2012 Report Share Posted June 11, 2012 There is a difference in the function gfd.SetLight between using it with the GFT8 and the GFRP48: While the setting and clearing of single lights independetly works on the GFT8, it shows a different behaviour on the GFRP48. There setting one light clears all the other lights. The gfd.SetLights function works the same for both modules. There is no difference in the code, it is identical. And the "SetLight" and "ClearLight" functions are merely wrappers for the "SetLights" function, preparing the two masks for you, that's all. It sounds as if you are using the GoFlight software too. It is not cooperative like FSUIPC -- it doesn't read the lights before changing them like FSUIPC does. The other possibility is a bug in the firmware in the unit which stops the reading of indicators working. I know that happened on the LGT2, but I don't think it happened on the RP48. GF never discovered it because as i said, they never use it. I don't know if that ever got fixed, but if not it only matters if you have separate programs accessing the same device. Regards Pete Link to comment Share on other sites More sharing options...
aua668 Posted June 11, 2012 Author Report Share Posted June 11, 2012 Hi, I only use FSUIPC to access my GF modules. I don't use the GF Software. To illustrate, I show some code segments and the result. On the GFT8 the following code: gfd.BlankAll()gfd.SetLight(GFT8, 0, 0)ipc.sleep(1000)gfd.SetLight(GFT8, 0, 1)ipc.sleep(1000)gfd.SetLight(GFT8, 0, 2)ipc.sleep(1000)[/CODE]produces the following result: LED 1,2 and 3 are turned to on with a interval of 1 second and at the end all thre LEDS are on.The same code by just replacing the GFT8 by GFRP48 lights up LED 1. After one second LED 1 turns off and LED 2 turns on and one second later LED 2 turns off and LED 3 turns on. If I use the gfd.SetLights function with the same mask for both modules I am able to turn on all three lights simultaneously. So for me it looks like, that the mask isn't filled correctly for the GFRP48 in the gfd.SetLight function. Should I address this to the GF support as you have checked this already in your code?RgdsReinhard Link to comment Share on other sites More sharing options...
Pete Dowson Posted June 11, 2012 Report Share Posted June 11, 2012 I only use FSUIPC to access my GF modules. I don't use the GF Software. ... So for me it looks like, that the mask isn't filled correctly for the GFRP48 in the gfd.SetLight function. There is no separate code for SetLight / ClearLight for any of the devices, just the one function each (Set and Clear) executed for all. And the code in the SetLights function, which uses the masks, is identical for almost all devices -- exceptions for the LGT2 for the firmware fault I mentioned, and weirder devices like the WP6 and DIO. I have run this here: gfd.BlankAll()gfd.SetLight(GFT8, 0, 0) ipc.sleep(1000) gfd.SetLight(GFT8, 0, 1) ipc.sleep(1000) gfd.SetLight(GFT8, 0, 2) ipc.sleep(1000) gfd.SetLight(GFRP48, 0, 0) ipc.sleep(1000) gfd.SetLight(GFRP48, 0, 1) ipc.sleep(1000) gfd.SetLight(GFRP48, 0, 2) ipc.sleep(1000) and I get the same as you on the T8 but also like the T8 on the RP48, no difference at all. I am using FSUIPC 4.834 and GFDev version 2.1.0.1. You didn't tell me the versions you are using, but assuming they are both up to date then the problem nust be in the firmware within the RP48 itself. Running HidScanner all i can tell you is that my RP48's say 'version 1.1.'. I've had them many years. Regards Pete Link to comment Share on other sites More sharing options...
aua668 Posted June 11, 2012 Author Report Share Posted June 11, 2012 Hi, I am using FSUIPC 4.831 at the moment but can try 4.834 too. For the GFDev I use the current version from the GoFlight Website. I will check, when I am at home. There might be one difference to your setup: I ordered the "RP48 mouse" module, which has additional functionality supporting mouse movements, and you might have the "standard" RP48. http://www.goflightinc.com/collections/modules/products/gf-rp48-mouse-push-button-rotary So there might be a firmware difference as you assumed. Rgds Reinhard Link to comment Share on other sites More sharing options...
Pete Dowson Posted June 11, 2012 Report Share Posted June 11, 2012 I ordered the "RP48 mouse" module, which has additional functionality supporting mouse movements, and you might have the "standard" RP48. Hmm. Never heard of the "RP48 mouse" version. There's bound to be different firmware. I'm afraid GF sometimes don't seem to test their firmware functions very fully -- their own software doesn't read the lights so they never worry about that function, it seems. I can program around it, but I'd rather do it only for that specific version if I can distinguish it. Could you run HidScanner and show me the entry for the RP48 in its log? (HidScanner can be found in the Lua thread in the Download Links subforum). The work-around assumes that the lights status reading function always returns zero. I keep a record of what I've already written and if I get zero back and i know I've set some I use my remembered settings instead of the read settings. It's messy and should be unnecessary, and it means it isn't cooperative with other programs (Lua or otherwise), but i had to do it like that for the LGT2 because of its firmware fault. Best also report it to GF as well please. They should know about it even if they find it, er, uneconomic, to fix it. [LATER] I folllowed the link and read about it, but it looks no different and it says nothing about the mouse function other than it has one, so how does that work? Why would it involve different hardware which looks identical? Regards Pete Link to comment Share on other sites More sharing options...
aua668 Posted June 11, 2012 Author Report Share Posted June 11, 2012 Hi, How it works is described here: http://goflight.vanillaforums.com/discussion/61/rp46-mouse-module I will do the test with HIDScanner tomorrow and post the result here. I am able to set any combination of lights with the gfd.SetLights function. This works for the RP48 module and for the T8 module if I put the combination for the LEDs I want to set in the "on" mask and 0xFF in the "off" mask. Then exactly those lights are turned on having the correspondent bits set. I will do some tests tomorrow and show you the results and if there are differences in handling of the masks. Rgds Reinhard Link to comment Share on other sites More sharing options...
Pete Dowson Posted June 11, 2012 Report Share Posted June 11, 2012 I am able to set any combination of lights with the gfd.SetLights function. This works for the RP48 module and for the T8 module if I put the combination for the LEDs I want to set in the "on" mask and 0xFF in the "off" mask. Then exactly those lights are turned on having the correspondent bits set. Yes of course, because by providing the settings for all of the lights there is no dependency on whatever is read from the device. Nevertheless, as i said, i can treat this erroneous version of the RP48 like the erroneous LGT2 if that would help -- even if you don't need it, others might. I await the HidScanner results. I will do some tests tomorrow and show you the results and if there are differences in handling of the masks. Sorry, I don't understand what more you think you can do or show? There's only the HidScanner data I want to see, please. Regards Pete Link to comment Share on other sites More sharing options...
aua668 Posted June 12, 2012 Author Report Share Posted June 12, 2012 Hi, Here is the HIDScanner.log for the GFT8: ************************************************************************** Device at "\\?\hid#vid_09f3&pid_0030#8&13b885f3&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}" Vendor=09F3, Product=0030 (Version 1.2) Manufacturer= GoFlight Product= GoFlight GF-T8 control module Serial Number= Usage Page: 2 Input Report Byte Length: 2 Output Report Byte Length: 0 Feature Report Byte Length: 2 Number of Link Collection Nodes: 4 Number of Input Button Caps: 1 Number of InputValue Caps: 0 Number of InputData Indices: 8 Number of Output Button Caps: 0 Number of Output Value Caps: 0 Number of Output Data Indices: 0 Number of Feature Button Caps: 1 Number of Feature Value Caps: 2 Number of Feature Data Indices: 3 Buttons range 1 -> 8 at indices 0 -> 7 **************************************************************************[/CODE]And here is the HIDScanner.log for my two units of the GFRP48 mouse show up like this:[CODE] ************************************************************************** Device at "\\?\hid#vid_09f3&pid_0028&mi_00#9&185b7c81&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}" Vendor=09F3, Product=0028 (Version 0.1) Manufacturer= Microchip Technology Inc. Product= Multi Media Keyboard Demo Serial Number= Usage Page: 2 Input Report Byte Length: 6 Output Report Byte Length: 0 Feature Report Byte Length: 2 Number of Link Collection Nodes: 4 Number of Input Button Caps: 1 Number of InputValue Caps: 1 Number of InputData Indices: 9 Number of Output Button Caps: 0 Number of Output Value Caps: 0 Number of Output Data Indices: 0 Number of Feature Button Caps: 1 Number of Feature Value Caps: 2 Number of Feature Data Indices: 3 Buttons range 1 -> 8 at indices 1 -> 8 Value Dial at index 0, range -128 -> 127, using 8 bits ************************************************************************** Device at "\\?\hid#vid_09f3&pid_0028&mi_00#9&efb9e4&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}" Vendor=09F3, Product=0028 (Version 0.1) Manufacturer= Microchip Technology Inc. Product= Multi Media Keyboard Demo Serial Number= Usage Page: 2 Input Report Byte Length: 6 Output Report Byte Length: 0 Feature Report Byte Length: 2 Number of Link Collection Nodes: 4 Number of Input Button Caps: 1 Number of InputValue Caps: 1 Number of InputData Indices: 9 Number of Output Button Caps: 0 Number of Output Value Caps: 0 Number of Output Data Indices: 0 Number of Feature Button Caps: 1 Number of Feature Value Caps: 2 Number of Feature Data Indices: 3 Buttons range 1 -> 8 at indices 1 -> 8 Value Dial at index 0, range -128 -> 127, using 8 bits ************************************************************************** Device at "\\?\hid#vid_09f3&pid_0028&mi_01#9&22e783de&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}" Vendor=09F3, Product=0028 (Version 0.1) Manufacturer= Microchip Technology Inc. Product= Microchip Technology Inc. Serial Number= Device is a mouse Usage Page: 1 Input Report Byte Length: 4 Output Report Byte Length: 0 Feature Report Byte Length: 0 Number of Link Collection Nodes: 2 Number of Input Button Caps: 1 Number of InputValue Caps: 2 Number of InputData Indices: 5 Number of Output Button Caps: 0 Number of Output Value Caps: 0 Number of Output Data Indices: 0 Number of Feature Button Caps: 0 Number of Feature Value Caps: 0 Number of Feature Data Indices: 0 Buttons range 1 -> 3 at indices 0 -> 2 Value Y at index 3, range -127 -> 127, using 8 bits Value X at index 4, range -127 -> 127, using 8 bits ************************************************************************** Device at "\\?\hid#vid_09f3&pid_0028&mi_01#9&2b8b98bf&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}" Vendor=09F3, Product=0028 (Version 0.1) Manufacturer= Microchip Technology Inc. Product= Microchip Technology Inc. Serial Number= Device is a mouse Usage Page: 1 Input Report Byte Length: 4 Output Report Byte Length: 0 Feature Report Byte Length: 0 Number of Link Collection Nodes: 2 Number of Input Button Caps: 1 Number of InputValue Caps: 2 Number of InputData Indices: 5 Number of Output Button Caps: 0 Number of Output Value Caps: 0 Number of Output Data Indices: 0 Number of Feature Button Caps: 0 Number of Feature Value Caps: 0 Number of Feature Data Indices: 0 Buttons range 1 -> 3 at indices 0 -> 2 Value Y at index 3, range -127 -> 127, using 8 bits Value X at index 4, range -127 -> 127, using 8 bits ************************************************************************** Device at "\\?\hid#vid_09f3&pid_0028&mi_02#9&320eaf6&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}" Vendor=09F3, Product=0028 (Version 0.1) Manufacturer= Microchip Technology Inc. Product= Multi Media Keyboard Demo Serial Number= Device is a keyboard Usage Page: 1 Input Report Byte Length: 9 Output Report Byte Length: 0 Feature Report Byte Length: 0 Number of Link Collection Nodes: 1 Number of Input Button Caps: 2 Number of InputValue Caps: 0 Number of InputData Indices: 110 Number of Output Button Caps: 0 Number of Output Value Caps: 0 Number of Output Data Indices: 0 Number of Feature Button Caps: 0 Number of Feature Value Caps: 0 Number of Feature Data Indices: 0 ************************************************************************** Device at "\\?\hid#vid_09f3&pid_0028&mi_02#9&b23f799&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}" Vendor=09F3, Product=0028 (Version 0.1) Manufacturer= Microchip Technology Inc. Product= Multi Media Keyboard Demo Serial Number= Device is a keyboard Usage Page: 1 Input Report Byte Length: 9 Output Report Byte Length: 0 Feature Report Byte Length: 0 Number of Link Collection Nodes: 1 Number of Input Button Caps: 2 Number of InputValue Caps: 0 Number of InputData Indices: 110 Number of Output Button Caps: 0 Number of Output Value Caps: 0 Number of Output Data Indices: 0 Number of Feature Button Caps: 0 Number of Feature Value Caps: 0 Number of Feature Data Indices: 0 **************************************************************************[/CODE]RgdsReinhard Link to comment Share on other sites More sharing options...
aua668 Posted June 12, 2012 Author Report Share Posted June 12, 2012 Hi, I did some tests with the on/off masks, which behave different between T8 and RP48: gfd.BlankAll()onMask1 = 0x0FonMask2 = 0xF0offMask1 = 0x55offMask2 = 0xAAgfd.SetLights(GFT8,0,onMask1, offMask1)ipc.sleep(1000)gfd.SetLights(GFT8,0,onMask2, offMask2)ipc.sleep(1000)gfd.SetLights(GGRP48,0,onMask1, offMask1)ipc.sleep(1000)gfd.SetLights(GFRP48,0,onMask2, offMask2)ipc.sleep(1000)[/CODE]These are the results shown as seen on the GF modules (left digit is ID 0, 1=ON, 0=OFF):[CODE]GFT8:1111000010101111GFRP48:0000000000001111[/CODE]As can be seen, the effect of the OFF mask is different. While at the T8 bits set without a corresponding bit in the ON mask, the light is turned off. Bits with zero don't affect. The behavour is strange. I found out, that only with a mask of 0xFF the value provided in the ON mask definitely is shown up.Maybe this helps for your workaround. For my setup I found a good solution to bypass this difference. I used a user offset for each module (1xT8, 2xRP48), where my LUA scripts can clear and set bits as needed and I just have one event per offset listening to changes on this offset, and then I simply pass the value of the offset as the ON mask with the OFF mask 0xFF to gfd.SetLights function for the module. This works perfectly.So a bypass from your side would be fine, as other users might also have problems using the gfd.SetLight function, which doesn't work as expected for that module.Rgds and thanks for your excellent support.Reinhard Link to comment Share on other sites More sharing options...
Pete Dowson Posted June 12, 2012 Report Share Posted June 12, 2012 I did some tests with the on/off masks, which behave different between T8 and RP48 If the reading of indicators from the RP48 isn't working because of a firmware fault, then the only sets of masks which will give consistent results are those where ALL the bits are accounted for. Where a bit isn't specified to be on or off, the value read back, incorrectly, will be used, and is likely to be always 0 (off). As can be seen, the effect of the OFF mask is different. While at the T8 bits set without a corresponding bit in the ON mask, the light is turned off. Bits with zero don't affect. The behavour is strange. Actually, the behaviour is astoundingly bad! Can you double-check, please? The logic in SetLights is as follows: X = readlights from device Y = X and (not ClearMask) Y = Y or SetMask writelights with Y For a working "readlights" your first test output would therefore do this: X = 0 Y = 0 and (not 0x55) = 0 Y = Y or 0x0F = 0x0F Note that the result being written is completely independent of the ClearMask, so it would be the same if that has been 0xFF. Note also that the written result always has non-zero bits meaning "light the LED", and that is going to happen independently of the return from "readlights" or the value of the clearMask, and yet your result shows no lights at all on the RP48. So, I can't see how you can ever get consistent results. even with 0xFF as "ClearMask", which you should expect, then as the above logic shows the only possibly incorrect lights with other ClearMasks much be only those lights not featured in the ClearMask. Maybe this helps for your workaround. No, if the device is operating unpredictably,.as your result shows, then no workaround seems possible. It won't set the lights i tell it to! So it is just a matter of luck whether you get the right results! BUT, for now I've assumed that my LGT2 workaround will work for this RP48 - i.e. that your findings above aren't typical -- and i'm making an update (4.835) with this workaround in. I'd be grateful if you'd try it directly, please, and see if it helps or if you still get the random results it appears you might from your tests. If you do confirm your very strange findings, I'll write to my contact in GoFlight and tell him that this version of the RP48 is simply not supportable as it stands. I hope you are submitting a bug report. If the workaround is, contrary to expectations, okay, then I'll apply it to FSUIPC3 and WideClient. But i'll wait for results first. I'll post a link to the update here in a short while ... Pete Link to comment Share on other sites More sharing options...
Pete Dowson Posted June 12, 2012 Report Share Posted June 12, 2012 I'll post a link to the update here in a short while ... FSUIPC4835test.zip Thanks, Pete Link to comment Share on other sites More sharing options...
aua668 Posted June 12, 2012 Author Report Share Posted June 12, 2012 Hi, I will test the provided update as soon as possible. I can confirm, that when I am not using 0xFF as the OFF mask, the result is more than astonishing and it's even more astonishing, that by using 0xFF it ALWAYS works. All other values show results, that are not predictable. Very strange indeed. That's why I shared these results with you. I think, they really have a bug in their firmware.Maybe their readlights from device is not consistent. Btw: Would it be possible to provide this readlights from device as a gfd.ReadLights (model, unit) function? This would be a nice new feature. Rgds Reinhard Link to comment Share on other sites More sharing options...
Pete Dowson Posted June 12, 2012 Report Share Posted June 12, 2012 I can confirm, that when I am not using 0xFF as the OFF mask, the result is more than astonishing and it's even more astonishing, that by using 0xFF it ALWAYS works. All other values show results, that are not predictable. Very strange indeed. But it is actually impossible, because the device cannot know what clear mask you've set. All it sees is the end resulting value I send it. It simply makes no sense. If it isn't consistent, it cannot be consistent when data it doesn't know anything about is one value as opposed to another. That's why I shared these results with you. I think, they really have a bug in their firmware.Maybe their readlights from device is not consistent. Well I could understand the readlights returning a random value, but that would only make random lights stay on or come on, it can never prevent lights you are explicitly lighting being lit! Btw: Would it be possible to provide this readlights from device as a gfd.ReadLights (model, unit) function? This would be a nice new feature. Well, it is possible, of course. I just don't see the point. What would be "nice" about it? Regards Pete Link to comment Share on other sites More sharing options...
aua668 Posted June 12, 2012 Author Report Share Posted June 12, 2012 Peter, I have now tested your version 4.835 and with this modification T8 and RP48 modules now work cmpletely the same way. I tested with the following program the gfd.SetLights, gfd.SetLight and gfd.ClearLight functions. And they showed exactly the same (and expected) output on the LEDs on all of my modules. gfd.BlankAll()gfd.SetLights(GFT8,0,0xAA,0x00)gfd.SetLights(GFRP48,0,0xAA,0x00)gfd.SetLights(GFRP48,1,0xAA,0x00)ipc.sleep(2000)gfd.SetLights(GFT8,0,0x55,0x00)gfd.SetLights(GFRP48,0,0x55,0x00)gfd.SetLights(GFRP48,1,0x55,0x00)ipc.sleep(2000)gfd.BlankAll()gfd.SetLights(GFT8,0,0xAA,0xFF)gfd.SetLights(GFRP48,0,0xAA,0xFF)gfd.SetLights(GFRP48,1,0xAA,0xFF)ipc.sleep(2000)gfd.SetLights(GFT8,0,0x55,0xFF)gfd.SetLights(GFRP48,0,0x55,0xFF)gfd.SetLights(GFRP48,1,0x55,0xFF)ipc.sleep(2000)gfd.BlankAll()lCnt = 0while lCnt < 8 dogfd.SetLight(GFT8,0, lCnt)gfd.SetLight(GFRP48,0, lCnt)gfd.SetLight(GFRP48,1, lCnt)ipc.sleep(200)lCnt = lCnt + 1endlCnt = 0while lCnt < 8 dogfd.ClearLight(GFT8,0, lCnt)gfd.ClearLight(GFRP48,0, lCnt)gfd.ClearLight(GFRP48,1, lCnt)ipc.sleep(200)lCnt = lCnt + 1end[/CODE]I went back to 4.831 and the difference was here again. Now I am back on your supplied version and as far as I could test all the other functions, which I have already implemented for my modules, they work perfectly.I have posted the bug report also in the GoFlight forum. Many thanks for your great support.Reinhard Link to comment Share on other sites More sharing options...
Pete Dowson Posted June 12, 2012 Report Share Posted June 12, 2012 I have now tested your version 4.835 and with this modification T8 and RP48 modules now work cmpletely the same way. I tested with the following program the gfd.SetLights, gfd.SetLight and gfd.ClearLight functions. And they showed exactly the same (and expected) output on the LEDs on all of my modules. Good. That makes sense assuming their "read lights" function always returns zero. The results you got with the mixed masks earlier, though, remain inexplicable. I don't see how those results were possible. I've added a "ReadLights" function to the GFD library, but it will of course always return zero on your RP48. It'll be included in the update 4.836 which i'll release tomorrow I expect, along with the FSUIPC3 version and WideClient. Thanks for the feedback! Regards Pete Link to comment Share on other sites More sharing options...
Pete Dowson Posted June 13, 2012 Report Share Posted June 13, 2012 FSUIPC 4.836 is now available, and the Lua documentation is updated in its thread in Download Links. Regards Pete Link to comment Share on other sites More sharing options...
aua668 Posted June 14, 2012 Author Report Share Posted June 14, 2012 Peter, I nstalled the new version and it works perfectly. Many thanks. Reinhard Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now