T-n-T: General Solution Development Tips

The problem

It is necessary to develop a solution based on CANNY controllers. This is my first experience with these controllers. Where to begin?

The solution

  1. Start by studying the documentation. Read all the chapters in sequence from the beginning to the description of the first controller model. The description of all controllers does not need to be studied. Study only the one you are going to use. Explore the examples in the sections that best suit your task. It does not take a lot of time.

  2. Scroll through forum, it discussed some of practical problems. The documentation and the forum are searchable.

  3. Use the simulator to debug your algorithms, but keep in mind that all input registers in the diagram are set to “0”, which does not reflect the actual operation of the controller. However, for debugging, the register values ​​in the simulator can be changed manually.

  4. Algorithms are easier to debug piece by piece. If something does not work as intended, create a separate diagram, copy and check in it the minimum components of your main diagram one by one, adding new ones in succession until you find an error. CannyLab supports copying and pasting through the clipboard Ctrl-C / Ctrl-V.

  5. Sometimes it is necessary to debug “in hardware”. In this case, you can use the controller’s built-in LED to monitor the values ​​at different places on the chart by connecting the “Controller’s built-in LED On Register” in turn to the various nets on your chart. In the same way, you can use the free discrete outputs of the controller or even send debugging information to the PC via UART or CAN (if there is something to accept it).

  6. Verify the performance of your solutions “on the bench” with test instruments and other controllers (see the next two points) before testing them in the field. If “on the table” your solution works, but not in the field, then most likely you will have to look for the cause yourself, since we are unlikely to be able to reproduce your field conditions at home.

  7. The controller itself can be a test signal generator for itself. For example, for your task, you can set up HR PWM on one of the channels and connect it from the outside on the controller connector with a wire to your counter input to check its operation. If you have a second controller available, then the possibilities of hardware debugging increase dramatically - one of the controllers can be a source of test signals / messages for another controller in standalone mode or in PC interface mode (CAN monitor, UART-CAN converter, etc.). P.).

  8. If you expect to use controllers in your projects repeatedly, then an OSCILLOSCOPE, even the simplest one, even the DSO138, starting at $25, is a great gift idea for you from family, friends or yourself. First of all, it’s funny! And secondly, the use of this device for troubleshooting and debugging solutions “in hardware” radically saves time and nerves. And both yours and technical support specialists.

  9. Consider the hardware limitations of the controllers - electrical characteristics, speed. The diagram does not execute instantly. The execution time of one cycle of the diagram depends on several factors. In particular, on the speed of the controller model, the size of the diagram, the workload of the controller drivers. Using time intervals of the order of milliseconds in a diagram is not a good idea, since the diagram itself can be executed in a longer time. The exact execution time of each cycle of the diagram during the operation of the controller can be obtained from the corresponding system register. For what requires a faster controller response, various drivers are implemented in the system software. For example: HR PWM Driver of CANNY 5.3 Pico, CAN Gateway Driver of CANNY 7.2 Duo, CAN Scheduled Asynchronous Transmitter Driver of CANNY 7.2 Duo.