Home Forums Software Interfacing with Python

Viewing 2 posts - 1 through 2 (of 2 total)
  • Author
    Posts
  • Cracked
    Participant
    Post count: 44

    I use the osPID to control a popcorn popper for roasting coffee. I have been using the front end software for a while on a Windows 7 machine, but recently switched to my ubuntu machine and couldn’t get Processing to find the controlP5 library.

    I took the opportunity to try to interface the osPID with some existing free software designed for coffee roasting. This was a challenge, as my programming experience is limited to VBA and one class in Javascript!

    I managed to pick up enough understanding of C to modify the firmware to output strings in the correct format for RoastLogger (freeware) and Artisan (open source).
    I am also attemping to output both the thermocouple and thermistor readings, but haven’t managed to get the thermistor reading working.

    I decided to fork the git repository for the firmware, although I have not yet managed to figure out how to push my cloned copy back to my fork via linux terminal (first time using git too!).

    After some successful roasts using RoastLogger, I found I really wanted the ability to make changes to settings, and start/stop profiles I decided to have a go writing my own gui application. Perhaps not the wisest choice for a first attempt at programming a gui application, and programming in python!
    I figure at first I can write some small scripts to change settings, and eventually roll them together into an application with a gui.

    So that is where I am now, trying to send commands to the osPID. I’m a bit stuck trying to understand the format of the serial communication to the osPID from the existing front end.

    I can send a byte array from python, but I can’t work out if I need to send the index for the case statement in SerialReceive, and then wait for a response from the osPID?

    Also, I notice in the code comments Brett mentions needing to send floats to the osPID. I can’t work out what data I could need to send to the osPID that would need hat much precision. I figure even the PID tuning parMeter I could simply multiply by 100, send as a long, and then convert back to a float and divide by 100 again on the other side. Am I missing something there?

    Brett
    Keymaster
    Post count: 101

    let me start by acknowledging that this comm protocol is a bit of a hack. it works, but it’s not something I’m particularly proud of.

    the main hints I would give for reverse engineering are the following:
    1. commands are always initiated by an identifier byte being sent (this corresponds to the case structure in serialreceive)
    2. after that, all bets are off. each command has a different sequence of information that comes after it. both the front-end and firmware know the rules though, so it winds up working ok.
    3. everything is sent as bytes. floating-point values are converted on the frontend using the floatArrayToByteArray function, and are converted back to float using a union structure. (everything you need to look at is in this file)

    with the float thing. a float is 4 bytes long (same as an int on the PC side) and was the most flexible option considering that I might need to send really small tuning values (0.0001? no problem) and really large profile values (30000 seconds, etc.)

    lastly, remember I wrote this two years ago, and that my specialty is pid control, not communication protocols. At this point, the arduino serial library may have advanced to the point where something far better can be written.

    Cheers!

Viewing 2 posts - 1 through 2 (of 2 total)
  • You must be logged in to reply to this topic.