AM/AP 3.7.10 Issues

[SimPassion]

 
In any case, with only the magnetos key added to a single instrument on a single panel, using the previously mentioned logic.lua script for it :

Code: Select all

05-04-2023 16:54:07 INFO AirPlayer: Version 3.7.10 HOME_USE 
.../...
05-04-2023 16:54:07 INFO LicenseFile: Program version: HOME_USE, License: HOME_USE_STANDARD, Valid until: Unlimited
05-04-2023 16:54:07 ERROR SiRunner: R150ST - ARDUINO - CHECK ONLY - HARDWARE HANDLING CLONE: logic.lua:22: Argument 'hw_id(2)' in function 'hw_switch_add' is not a string, which is not allowed
05-04-2023 16:54:07 ERROR SiRunner: R150ST - ARDUINO - CHECK ONLY - HARDWARE HANDLING CLONE: logic.lua:24: Argument 'id(1)' in function 'hw_switch_get_position' is nil, which is not allowed
05-04-2023 16:54:07 ERROR SiRunner: R150ST - ARDUINO - CHECK ONLY - HARDWARE HANDLING CLONE: logic.lua:25: Argument 'id(1)' in function 'hw_switch_get_position' is nil, which is not allowed
.../...
05-04-2023 16:54:20 INFO HardwareArduino: Mapped Arduino(ARDUINO_2560, channel A, PIN) on port 'COM4'
05-04-2023 16:54:20 INFO HardwareArduino: Mapped Arduino(ARDUINO_UNO, channel A, PIN) on port 'COM3'

[SimPassion]

 
For Info, just checked it seems to works with Air Player 3.7 Beta 20, should we stay on degraded mode ?
 

[SimPassion]

 
Eventually network issues were coming, together with Air Player launch freeze after adding more instruments

Frozen situation again ! ...

So, still needing advice from @Corjan, on what can be done to unlock the situation, with help from SI ... ???

[EDIT] Just to mention, I've performed cross checks with :

• AM 3.7.10 and AP 3.7.10
• AM 3.7 Beta 32 and AP 3.7.10
• AM 3.7.10 and AP 3.7 Beta 20
• AM 3.7 Beta 32 and AP 3.7 Beta 20

No way in any case !!!
 

[SimPassion]

Correlated thought, I think it's more than time to build Air Player package, targeting Desktop x64 platform : not 32 bits only but, rather true 64 bits with direct execution on AMD64 CPU spec, or "Any CPU" target that will allow the execution context to be automatically selected on launch, depending on CPU ADM64/x86 specs ... !!!!

image.png (805 Bytes) Viewed 2707 times

[SimPassion]

32 bits only targeted APPs have to disappear in the AMD64 CPU context and are very highly well-known, as source of complication and execution errors triggering while running on AMD64 CPU spec ...

To clarify further, by design ...

32 bits apps will run :

• In 32 bits mode on 32 bits OS
• In 32 context on 64 bits OS

true "Any CPU" apps (x86/AMD64), where AMD64 refer to x64 CPU architecture, will run :

• In 32 bits mode on 32 bits OS
• In AMD64 context on 64 bits OS

[SimPassion]

 
@Corjan and @Ralph, is there any hope to use properly Arduino on remote Air Player 3.7.10 ?
 

[Ralph]

There's just too much information here to go trough. Please make a short description of the problem.

[SimPassion]

There's just too much information here to go trough. Please make a short description of the problem.

In short :

as already explained through the following link, where all is summarized : https://siminnovations.com/forums/viewt ... 455#p53455,

1. after sending an hardware only instrument, from Air Manager 3.7.10 to Air Player 3.7.10
2. then exiting and restarting Air Manager, displaying Air Player device Hardware Binding,
3. I get this in the screenshot below, where some binding have disappear :

again, initial explanation from reported link : "I have only part of the whole binding made for the moment (I will add a bunch of buttons inputs and multiple encoders later, if all is working properly at first)
So, currently, hardware inputs like 1 x adc input, 10 x buttons input and a 5 x rotating switch input, I've bind on an Arduino Mega 2560, with additional 2 x buttons input on an Arduino Uno.
The issue come when I save the configuration to the Air Player, most of the binding is retained and properly shown, but the last rotating switch binding disappears from the device configuration, after Air player has restarted and I reload Air Manager. At the same time, indeed INFO SiRunner is mentioning "Failed to bind hardware" in the Air Player logs."

After having also checked with my own AM 4.1.6 / AP 4.1.6 install, I found even worse situation, where the named binding are not taken in account at all. So I'm just wondering if Air Player is a stable enough solution and the way to go ... ???
 

[SimPassion]

Well, do you really think I have time to answer so many answers a day providing so much help, suggestions, advice, examples ... no, I have life also, don't be so many willing to help at a time ...

In any case, thanks to make me helping myself, with 5 days/night to investigate on this issue
So I will report again, hoping it will be useful for any new comers :

I've always used NAMED hardware, which I think is really the way to deliver to the community, as we don't know in advance how each one will plan his own hardware input binding.

the statement is using NAMED input for switches works in Manager, however absolutely not in Air Player 3.7.10 at least and for hw_switch_add only (not already checked for every single hardware input statement and usage, however at the moment hw_button_add seems to work properly, will check next with other like encoders/dials, leds, output, pwm ...), with error reported on syntax usage and don't seems to work that much on Air Player 4.1 and 4.2 Beta, as opposed to what we read on the wiki :

which is totally false/wrong statement for Air Player :
Hardware Id's
Info Hardware Id's are not preferred, try to use named hardware instead.

Define the used pin(s) right away. This is not preferred, since changing of pin assignment can only be done by changing the instrument/panel lua script.

here's what Air Player 3.7.10 is reporting, for example :

Code: Select all

logic.lua:22: Argument 'hw_id(2)' in function 'hw_switch_add' is not a string, which is not allowed

So, if one expect their own instrument to be also usable in Air Player for other simmers, we have to not use NAMED hardware binding for hw_switch_add statement, but rather ID's hardware binding for obvious proper reliability


I can't understand the background :

• Why Air Player 3.7 didn't got a fix for this
• Why Air Player area seems to be the neglected part of the story, even with Air Player 4.n, at least AFAIK and we don't know if an upcoming new project/application will or will not replace Air Player. Will Air Player become an abandonment-ware ???

At least correct the statement above on wrong/false preferred usage of NAMED vs ID's hardware binding to not lead community and simmers into confusion and wrong assertion/assumption.

I've already read many wondering and statement here on the forums, around Arduino together Air Player usage. Among them Keith already alerted on the issue and it seems actions have not followed, not advice taken in consideration, so hurry up !!!

Behind, this there's also obviously lack of clear explanations on what Air Player and Air Manager are doing properly or not in the background, here's one sample where AP 3.7.10 haven't been fixed yet for a well-known issue which still occurs from time to time :
https://siminnovations.com/forums/viewtopic.php?t=3971

Not sure if this has been taken in consideration :
https://siminnovations.com/forums/viewtopic.php?t=1810

Keith's alert on Air Player NAMED hardware issue which is fully confirmed now and eventually and not already fixed for any Air Player version :
https://siminnovations.com/forums/viewt ... 953#p29953


No need for answer to this, thanks to all and enjoy proper usage of Air Manager / Air Player suite, each one performing own part.
... and thanks SI building reliable, dynamic, friendly user applications ... hope the best to all including all of us simmers !!!
 

[Keith Baxter]

Gilles,

Silly question. Are you flashing the arduino with 3.7.x ?

Keith