In Part 3 of my ISOBUS Task Controller series, I promised to get this Part 4 out close to the time of Spring Plugfest … and I missed by over a month. Regardless, here is Part 4.
In this Task Controller (TC) series, I have detailed data collection and variable-rate application. The final big feature of TC is Section Control. This feature also has an ISOBUS Functionality called TC-SC. Most people have an idea what section control is, but for the uninitiated … section control will turn on/off various controllable sections of an implement to avoid overlap in a field. The primary benefit is reduced input cost for the farmer. Less seed or spray or fertilizer applied to a field the better. In many cases, over-application is detrimental so it should even have a positive impact on yield. Another benefit, also related to reduced inputs, is the reduced impact on the environment due to over-application and run-off.
The textbook ISOBUS scenario for a TC exchange places relatively few demands on the TC-Client (i.e. the implement). The implement tells the TC, via its object pool, how the sections are configured and then it just listens to TC commands to turn on or off the various sections. It is up to the TC to keep track of where application has already taken place, where each section is in geometric space, and do the appropriate look-ahead calculations to command each section in a predictive manner to get it to turn on or off when it should. No doubt the TC has a harder job in this exchange, but in typical practice the TC-Client has a little harder job than it otherwise may seem. Many implements with multiple units, e.g. a sprayer or planter, will have multiple sections composed of multiple rows. The specific configuration of these sections can typically be configured by a user. This implies a dynamic object pool after user configuration rather than a static pool that works for every scenario.
The other big complication for the TC-Client relates to the limitations of the TC in terms of the number of sections it will support. These are generally computational limits of the TC computing hardware itself. The newer version of the TC standard has information exchanged between the TC and the TC-Client to allow the TC-Client to know the section-control limitations of the TC. It is then up to the TC-Client to modify the object pool – again, dynamically – to fit into the limitations of the particular TC. There is no standardized method to do this; it is up to the manufacturer.
That wraps up the description of the core features of Task Controller in ISOBUS. There are a few newer features that are worth mentioning and I will discuss those in the fifth segment of this blog series in a few weeks. Click here for Part 5 of this series. Or to review Part 3, click here.
