Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implementing a switch based sectionControl - based on the code by MTZ8302 #537

Open
wants to merge 11 commits into
base: develop
Choose a base branch
from

Conversation

hagre
Copy link

@hagre hagre commented Jan 6, 2025

I was inspired by the solution of MTZ8302 to build a section-control-box for my equipment. I found his solution very interesting, but the switching (MAN/AUTO,... ) logic is not exactly fitting my needs at the moment. I prefer to have section controlling priority with switches – not with buttons - so I can feel the selected state even without looking at the indication (switch-box or AOG). To toggle the AGO section state (ON/AUTO/OFF) on the screen is not necessary in my case.

Each Section has an ON / AUTO / OFF Position (3 position switch):
The (top) ON position is always setting the section to ON, as long as the MAIN switch in not avoiding that. So it is manually overriding the AOG output to ON.

The (middle) AUTO position is setting the section to the incoming AOG request, as long as the MAIN switch in ON.

The OFF position is setting the section always to OFF. So it is manually overriding the AOG output to OFF.

I am additional using on MAIN Switch with an ON / OFF / EXTERNAL position (3 position switch – 2 positions is possible if the EXTERNAL option is not needed):
The ON position is giving the switch-box the possibility to select all sections to ON, if they are in (top) ON or in the (middle) AUTO position, when an ON signal is received from AOG.

The OFF position is switching all sections to OFF regardless of anything else.

The EXTERNAL position (bottom) has more or less the ON functionality, but with the additional necessarily to have an “external” switch in the ON position as well, to giving the switch-box the possibility to switch all sections ON.
This external switch could be used as an overriding safety-master-switch mounted on very convenient ( quick to reach) location, e.g. if you are not happy with the auto mode during tight turns in problematic corners of the field or during “offline” usage of the switch-box to avoid the need of reaching out to the switch-box behind you, … .
It could well be used like the work switch of the equipment, to avoid “painting” when the tool is not in the right configuration or working position.

So my solution is this PR:
Additional to the initial buttons solution by MTZ8302 - ( both hardware setups are possible )- the “new” hardware is sending a bit in its standard PGN234 to select the way AGO will be processing the received information. The old "unused" 3rd bit of the main byte (5th byte) is now used for this. MTZ8302 existing hardware is/was sending 0, in my solution a 1 is sent.

Byte 6 and 7 (old unused “Reserved” bytes) of PGN234 are now used to transmit the "Auto"-state of the sections switches. The transmitting style is the same way as the existing On and OFF Bytes are done.
Now, for the section/switch control hardware, it is possible to inform AGO about the exactly desired state of the sections/switches!
The section-control-box keeps controlling the tool in “offline” mode (no AOG connection) – during connection problems or even on a different tractor without AOG tablet at all.

farmerbriantee and others added 5 commits January 6, 2025 06:55
…8302

I was inspired by the solution of MTZ8302 to build a section-control-box for my equipment. I found his solution very interesting, but the switching (MAN/AUTO,... ) logic is not exactly fitting my needs at the moment. I prefer to have section controlling priority with switches – not with buttons - so I can feel the selected state even without looking at the indication (switch-box or AOG). To toggle the AGO section state (ON/AUTO/OFF) on the screen is not necessary in my case.

Each Section has an ON / AUTO / OFF Position (3 position switch):
The (top) ON position is always setting the section to ON, as long as the MAIN switch in not avoiding that. So it is manually overriding the AOG output to ON.

The (middle) AUTO position is setting the section to the incoming AOG request, as long as the MAIN switch in ON.

The OFF position is setting the section always to OFF. So it is manually overriding the AOG output to OFF.

I am additional using on MAIN Switch with an ON / OFF / EXTERNAL position (3 position switch – 2 positions is possible if the EXTERNAL option is not needed):
The ON position is giving the switch-box the possibility to select all sections to ON, if they are in (top) ON or in the (middle) AUTO position, when an ON signal is received from AOG.

The OFF position is switching all sections to OFF regardless of anything else.

The EXTERNAL position (bottom) has more or less the ON functionality, but with the additional necessarily to have an “external” switch in the ON position as well, to giving the switch-box the possibility to switch all sections ON.
This external switch could be used as an overriding safety-master-switch mounted on very convenient ( quick to reach) location, e.g. if you are not happy with the auto mode during tight turns in problematic corners of the field or during “offline” usage of the switch-box to avoid the need of reaching out to the switch-box behind you, … .
It could well be used like the work switch of the equipment, to avoid “painting” when the tool is not in the right configuration or working position.

So my solution is this PR:
Additional to the initial buttons solution by MTZ8302 - ( both hardware setups are possible )- the “new” hardware is sending a bit in its standard PGN234 to select the way AGO will be processing the received information. The old "unused" 3rd bit of the main byte (5th byte) is now used for this. MTZ8302 existing hardware is/was sending 0, in my solution a 1 is sent.

Byte 6 and 7 (old unused “Reserved” bytes) of PGN234 are now used to transmit the "Auto"-state of the sections switches. The transmitting style is the same way as the existing On and OFF Bytes are done.
Now, for the section/switch control hardware, it is possible to inform AGO about the exactly desired state of the sections/switches!
The section-control-box keeps controlling the tool in “offline” mode (no AOG connection) – during connection problems or even on a different tractor without AOG tablet at all.
Code cleanup of exitsting code  and use of new PerformSectionClick()
@richardklasens
Copy link
Collaborator

@farmerbriantee added this in the release. I will close the PR

@richardklasens
Copy link
Collaborator

This was the wrong one to close. Sorry

@richardklasens richardklasens reopened this Jan 6, 2025
@Pat-I
Copy link

Pat-I commented Jan 6, 2025

Hi Hagre and the team
So questions
This PR would force AOG to change the section output? Like turn it on or off?

What do you think about just use this same PGN structure but read the 0 or 1 as section " actual status(enabled/disabled)"? Don't change the AOG Off/Auto/On mode.

If the 3th bit in the fifth byte is 1 then just swicth to "feedback mode" ie instead AOG controling the painting it would be the bits in the bytes 6 and 7. Using the already used purple and blue section colors if actual section status doesn't match the desired AOG status

And did you looked if you could use the ISOBUS stuff @lansalot is working on?
#525

@hagre
Copy link
Author

hagre commented Jan 6, 2025

Hello again.
I just found a possible error in my explanation with the bits and bytes of the PR, maybe that started some confusion. Sorry for that.

The actual structure of pgn234 (out of the CModuleComm.cs) is:

swHeader = 0, swMain = 1, swReserve = 2, swReserve2 = 3, swNumSections = 4, swOnGr0 = 5, swOffGr0 = 6, swOnGr1 = 7, swOffGr1 = 8;

That defines “swMain” as byte 1, the unused “swReserve” as 2 and, “swReserve2” as 3.
I started to count with 0 from the absolute beginning of the PGN234 including all header bytes and so on. That is the way the PGN5.7.xlsx is written.

@FantasyTeddy
Sometimes Github is relay confusing me. My PR original consists of changes in 2 files, now it looks like 48 files are involved. Is this due to other PRs are already pushed and my base is not in sync any more?
And I have an additional request to you: richardklasens told me via telegram, that i could ask you nicely to verify the function of the existing MTZ8302 code. Hopefully I haven’t broken his code during my try to clean it up a little bit. At the moment, I do not have the actual hardware on hand to test it. It would be nice to know someone with the an already working equipment to test the code, otherwise i have to build me a test-bench for it.

Hi @Pat-I
I try to understand your question, but I am struggling with the answer.

This PR is not changing the section output of AOG directly (Not the - red, blue, purple, yellow, green – triangles behind the tool). It is just adjusting the manual-ON/AUTO/manual-OFF (yellow/green/red colored rectangles with the section number in it) for each section in AOG corresponding to the switches position of the box, and maintain this state even if you press the button on the screen (correct it back to the desired switch-state of the external switch-box in the same second).

AOG is still doing the painting job for the sections on the map. The color change between - red, blue, purple, yellow, green is normal and not touched by the PR.

I have now looked at the “Integrate ISOBUS section control as a separate class #525” Issue. That could potentially do the trick for me as well, if it is implemented in the future!

I am very interested in the feedback mode you have mentioned, because than it would be possible to report the actual valve position (OPEN/CLOSE) back to AOG and to start and stop the painting accordingly.

I have tried to do that by sending back the actual status of the valves with the hello - “machine replay “ (pgr123) at byte 5 “relayLo” and byte 6 “relayHi”. It doesn’t look like it worked until now. Is there something different to use for “feedback” to AOG?

hagre added 3 commits January 6, 2025 20:21
…8302

I was inspired by the solution of MTZ8302 to build a section-control-box for my equipment. I found his solution very interesting, but the switching (MAN/AUTO,... ) logic is not exactly fitting my needs at the moment. I prefer to have section controlling priority with switches – not with buttons - so I can feel the selected state even without looking at the indication (switch-box or AOG). To toggle the AGO section state (ON/AUTO/OFF) on the screen is not necessary in my case.

Each Section has an ON / AUTO / OFF Position (3 position switch):
The (top) ON position is always setting the section to ON, as long as the MAIN switch in not avoiding that. So it is manually overriding the AOG output to ON.

The (middle) AUTO position is setting the section to the incoming AOG request, as long as the MAIN switch in ON.

The OFF position is setting the section always to OFF. So it is manually overriding the AOG output to OFF.

I am additional using on MAIN Switch with an ON / OFF / EXTERNAL position (3 position switch – 2 positions is possible if the EXTERNAL option is not needed):
The ON position is giving the switch-box the possibility to select all sections to ON, if they are in (top) ON or in the (middle) AUTO position, when an ON signal is received from AOG.

The OFF position is switching all sections to OFF regardless of anything else.

The EXTERNAL position (bottom) has more or less the ON functionality, but with the additional necessarily to have an “external” switch in the ON position as well, to giving the switch-box the possibility to switch all sections ON.
This external switch could be used as an overriding safety-master-switch mounted on very convenient ( quick to reach) location, e.g. if you are not happy with the auto mode during tight turns in problematic corners of the field or during “offline” usage of the switch-box to avoid the need of reaching out to the switch-box behind you, … .
It could well be used like the work switch of the equipment, to avoid “painting” when the tool is not in the right configuration or working position.

So my solution is this PR:
Additional to the initial buttons solution by MTZ8302 - ( both hardware setups are possible )- the “new” hardware is sending a bit in its standard PGN234 to select the way AGO will be processing the received information. The old "unused" 3rd bit of the main byte (5th byte) is now used for this. MTZ8302 existing hardware is/was sending 0, in my solution a 1 is sent.

Byte 6 and 7 (old unused “Reserved” bytes) of PGN234 are now used to transmit the "Auto"-state of the sections switches. The transmitting style is the same way as the existing On and OFF Bytes are done.
Now, for the section/switch control hardware, it is possible to inform AGO about the exactly desired state of the sections/switches!
The section-control-box keeps controlling the tool in “offline” mode (no AOG connection) – during connection problems or even on a different tractor without AOG tablet at all.
Code cleanup of exitsting code  and use of new PerformSectionClick()
@FantasyTeddy
Copy link
Collaborator

Oh I'm really sorry, this is actually my fault. We are still figuring out the ideal process for how to do our collaboration and I had to cleanup the develop branch and used the "forbidden" force-push, wich lead to the confusion in GitHub.
I rebased your changes and it should now be again 3 commits and 2 changed files, correct?

For your additional request I have to say that I'm not familiar enough with this functionality that I could verify if everything works correctly. I also don't have any hardware that I could test this with, so it would take me quite some time to figure all this out.
If you can't find anybody that actually can verify the functionality, I will of course try to set something up to hopefully do it myself, but someone with a working setup can do that much faster.

@hagre
Copy link
Author

hagre commented Jan 6, 2025

@FantasyTeddy
Thank you for the quick replay. Now I understand.

Regarding the hardware – I will try to find someone to assist in testing. @mtz8320 :)

@hagre
Copy link
Author

hagre commented Jan 8, 2025

Update:
@FantasyTeddy
I have just phoned with mtz8302. He has tested the code successfully. There is NO negative influence by this PR to his functionality.

Copy link
Collaborator

@FantasyTeddy FantasyTeddy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you need help with cleaning up the Git history? (There are currently 11 Commits shown, where only 3 are really relevant...)

@@ -563,182 +563,373 @@ private void BuildMachineByte()

private void DoRemoteSwitches()
{
//MTZ8302 Feb 2020
//MTZ8302 Feb 2020 and hagre 2024
int Bit;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do not define variables at the top, but where they are actually being used.

//MainSW was used
if (mc.ss[mc.swMain] != mc.ssP[mc.swMain])
//check if third bit in the pgn234 received Main-Byte is set to indicate the use of buttons (0) or switches (1) in the SC hardware
if ((mc.ss[mc.swMain] & 4) != 4) // Button hardware by MTZ8302 Feb 2020
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we maybe introduce 2 new methods: one called something like HandleButtonHardware with the content of this if block and one like HandleSwitchHardware with the content of the else if block?

// ON Signal from Arduino
for (int i = 0; i < 8; i++)
{
Bit = (int)Math.Pow(2, i);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think when dealing with bit-operations, it is best to use bit shift operations (like <<) instead of "proper" mathematical operations.
Maybe we could also think about adding some helper functions that would simplify such bit checking...?

}
mc.ssP[mc.swOffGr0] = mc.ss[mc.swOffGr0];

/// OFF Signal from Arduino
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only use double // for comments (triple /// are used for documentation comments).

}

}
else if ((mc.ss[mc.swMain] & 4) == 4) // Switch hardware by hagre 05 2024
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this need to be an else if or could it just be else, because you are just checking the inverse of the if?

// zones to on
if (mc.ss[mc.swOnGr0] != 0)
//check if third bit in the Main-Byte is set to signal buttons (0) or switches (1) used in the SC hardware
if ((mc.ss[mc.swMain] & 4) != 4) // Button hardware by MTZ8302 Feb 2020
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here too: maybe add a method HandleButtonZones for the if block and a HandleSwitchZones for the else if block.

@SK21
Copy link
Collaborator

SK21 commented Jan 8, 2025

Update: @FantasyTeddy I have just phoned with mtz8302. He has tested the code successfully. There is NO negative influence by this PR to his functionality.

I also tested with my switch code and it worked ok.

@richardklasens
Copy link
Collaborator

@hagre can you also update the XLS file with the PGN’s you added?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants