Hardware/Software Synergy

[Keith Baxter]

At the moment there is NO Synergy in the way Software and Hardware can be programmed and I do not see a reason why they should not be exactly the same. I am hereby requesting that there be a "NAMED SOFTWARE" option to work EXACTLY the same as the "NAMED HARDWARE".

What would be the benefits of such a feature? Well

1) Coding would be consistent between the two types.
2) Instruments coded for software devices would not have to be modified to accommodate hardware devices. One just needs to assign the relevant arduino and pins to make them work.

Here is how I see it working.

Just like AM recognizes that a "NAMED HARDWARE" device if it is specified in code, it recognizes "NAMED SOFTWARE". This could be two separate tabs in the console or the two could be combined.
So in the properties tab, one can either assign to a hardware pin or not. Next to Pin pos one has the ability to change the name of the Pin position. This would keep consistency between the sim pin position name (value in the sim dataref) and pin position name used by AM.

So what have we achieved if the above it implemented.

Ease and consistency in the way devices are coded in script.
Instruments coded for software devices are dual purpose and hardware devices are simply added the way one does in "NAMED HARDWARE"
One does not have to enter a value in dataref subscription and click "send" One simply clicks the "NAMED DEVICE" switch position when testing and debugging.

Corjan, I hope this finds appetite with you as I believe it would be a huge benefit. Not sure how difficult this would be to implement, I hope not to difficult.

Keith

[Keith Baxter]

To add to my above post.

In the properties tab one could also have the option to select the type of cursor. For example the right & left turn arrows, or the up & down toggle switch arrows or the left & right toggle switch arrows etc, etc.

Keith

[Sling]

Keith,

Please see my post in the other thread re the differences between hardware and software switches. I personally think the switch_add is fine as it is and has already been used in loads of instruments successfully. I’ll think about doing another video showing the interface with negative value datarefs.

Tony

[Keith Baxter]

Keith,

Please see my post in the other thread re the differences between hardware and software switches. I personally think the switch_add is fine as it is and has already been used in loads of instruments successfully. I’ll think about doing another video showing the interface with negative value datarefs.

Tony

Tony,
We cross posted in the two threads.

I politely total disagree with you Tony. I discussed here and in the other thread the reasons.

To be honest and please don't get me wrong here, I don't really mind if the AP is changed or not to add this feature. But it sure would go a long way to assist me and others.
Just some background as to how all this has come about.
I started to produce hardware instruments for the Zibo. The first one was the EFIS controller. As I had used some of your and Gilles code, I sent Gilles the instrument to test. Gilles then suggested that that code be added to his Zibo EFIS instrument so that the instruments in the store become dual usage compliant.

So that is how and why I am now doing instruments that are dual compliant. I say this with a tongue in my cheek, "IT SUCKS" that one has to do two different types of code in the same instrument where one short simple code could do the same job.

I am not saying do away with the old code. Just adapt the named hardware to work in named software. I guarantee you that no more instruments will be written using the old complicated switch_add() method. Especially when used in conjunction with canvas_draw()

I sure hope that this explanation also gives you appetite to support the request.

Keith

[Sling]

Keith,

I think you are over looking or perhaps not understanding the differences.

1. The soft operation of hardware switches is purely for development purposes. The hw add is intended to add a hardware switch. When that switch is connected it’s actual position can be established on instrument start. You cannot do this with a software switch without further code. It may seem move complicated but it’s because of the nature of each type of switch add.

2. When adding hw to an existing instrument as with the online instruments normally the software switch code is already done and it’s just a case of adding the hw. In a lot of cases you can use the existing callbacks without change.

3. The software switch can be open or closed loop(sim feedback) which is why you need the position to be separated from the add callback. The wiki explains both methods. With closed loop the switch position is updated when the sim changes so it allows control via the sim or AM switch. With hw the switch operation can only ever be open loop.

4. You need image, xy position and size arguments for a soft switch that are not required for a hw switch.

[Keith Baxter]

Keith,

I think you are over looking or perhaps not understanding the differences.

1. The soft operation of hardware switches is purely for development purposes. The hw add is intended to add a hardware switch. When that switch is connected it’s actual position can be established on instrument start. You cannot do this with a software switch without further code. It may seem move complicated but it’s because of the nature of each type of switch add.

2. When adding hw to an existing instrument as with the online instruments normally the software switch code is already done and it’s just a case of adding the hw. In a lot of cases you can use the existing callbacks without change.

3. The software switch can be open or closed loop(sim feedback) which is why you need the position to be separated from the add callback. The wiki explains both methods. With closed loop the switch position is updated when the sim changes so it allows control via the sim or AM switch. With hw the switch operation can only ever be open loop.

4. You need image, xy position and size arguments for a soft switch that are not required for a hw switch.

Very valid points Tony.

Here is my rebut.

1) Yes that is my point. I want the code that operates the soft operation to operate the "Named software" switch. As an example lets take 10 euros. It is used to pay for things. Payment can be made by swiping your debit card or fiscally handing over a bank note. The end result is the payment. The same must be said for the "Named Hardware" and "Named Software" switches. They both tell the sim what to do.

2) I have no problems with having to add code to existing instruments to make them hardware compliant. It is having to write two processes when creating new instruments. There is no benefit in writing two processes or keeping them separate.

3) I thought the the point of having a switch, be it hardware or software, was to tell the sim what position the the switch should be in. Not for the sim to tell the switch what position it should be in. The only exception I can think of is if one wants to code flight controls for dual operation so that a yoke or peddles can be operated by a mouse if there is a FO pilot.

4) Yes one does require an image for soft switches. However It is very cumbersome to add six or seven images for each position the switch is in. It is far easier to just rotate one image. So to add "space" to a canvas where a switch will be is to simple give it the x,y,w,h if the instrument is to be used for dual purpose of for soft switch only purposes.

Now you are going to ask what do you with the soft instrument when one only requires the instrument for hardware operation. You can simply make the instrument invisible.


I think what one has to decide is. Is there any benefit in doing it this way, does it make sense to have just one simple code and how difficult is it to implement.

Keith

[SimPassion]

Ok, let's take an example to see if I understand well

Perhaps Corjan could confirm if something like this could be achieved as a new feature ?
cpt_main_du = switch_add(nil,nil,nil,nil,nil,25, 25, 50,50,hw_enable,main_du)

but in this specific case, it looks like we need different coding to handle either software switch or hardware switch

cpt_main_du = switch_add(nil,nil,nil,nil,nil,25, 25, 50,50,main_du)

cpt_upper_sw_DU = hw_switch_add("CAPT Upper DU",5, cpt_upper_DU)

• as for the software the values increasing from -1 to 3 are hardware coded in ZiboMod by design and we can't do anything than transcoding these values to fit the software knob rotation
• for the hardware it is defined internally in Air Manager by design from 0 to 4 and there we can't do anything else than following the position returned

Gilles

[SimPassion]

Another idea, perhaps something like this ?

cpt_main_du = switch_add(nil,nil,nil,nil,nil,25, 25, 50,50,hw_enable,software_callback,hardware_callback)

Gilles

[Keith Baxter]

Ok, let's take an example to see if I understand well

Perhaps Corjan could confirm if something like this could be achieved as a new feature ?
cpt_main_du = switch_add(nil,nil,nil,nil,nil,25, 25, 50,50,hw_enable,main_du)

but in this specific case, it looks like we need different coding to handle either software switch or hardware switch

cpt_main_du = switch_add(nil,nil,nil,nil,nil,25, 25, 50,50,main_du)

cpt_upper_sw_DU = hw_switch_add("CAPT Upper DU",5, cpt_upper_DU)

• as for the software the values increasing from -1 to 3 are hardware coded in ZiboMod by design and we can't do anything than transcoding these values to fit the software knob rotation
• for the hardware it is defined internally in Air Manager by design from 0 to 4 and there we can't do anything else than following the position returned

Gilles

Gilles your understanding is very close.
This is how I think it would easily work with only one device_add. AM could be taught to treat both hw_switch_add() and soft_switch_add() the same way.

You can see in the structure below that I have put things in specific places to make it easy for AM to read the string.

cpt_main_du= switch_add("CPT Upper DU" ,5, rotary, -1, 3, image, image_n, x,y,w,h, callback)


If this switch_add() is used for a "NAMED HARDWARE" then the image, and image_n, x,y,w,h is ignored.
If the switch_add() is used for a "NAMED SOFT WARE" then the image and image_n, x,y,w,h are taken into account.
The switch position numbers are assigned to the switch and show in the console.
From here on AM handles both soft and hard devices the same way that AM currently handles "NAMED HARDWARE"

Keith

[Keith Baxter]

Another idea, perhaps something like this ?

cpt_main_du = switch_add(nil,nil,nil,nil,nil,25, 25, 50,50,hw_enable,software_callback,hardware_callback)

Gilles

Gilles,

You don't need hw_enabled and the different callback's. The hardware is enabled by assigning the pins in the console. The callbacks are the same for both soft and hardware devices. Just like they are now.
Keith