Blog Post Actions
Group Actions
Engagement
  • Author Author: djfraz
  • Date Created: Date Created
  • Views 232 views
  • Likes 0 likes
  • Comments 4 comments
Related
Recommended

Third Year Systems Project - 3: Begining to look like Something

djfraz

Some fun news first, We now have a logo for the "Company" (as this is a mock project, its a mock company). We are Called Alpha Vending Solutions

image

 

I have just managed to get working the Maintenance mode Software using visual c#. The fix to get the serial port object to work was annoyingly simple once I found it.

The main use of this software will be to test functionality of the system, Send servo commands, read sensors and such. As we still are not fully sure on what software we will need, it has been made as a MDI (Multiple Document Interface) to allow more forms and controls to be added as needed.

image

The fix i found for getting the serial ports to work over multiple forms was to pass the Serial Port which has been opened in the main form to the other forms as an argument, see bellow

On the Form to be opened

 

using System.IO.Ports;
SerialPort serial = new SerialPort();
public Servo(SerialPort port)
        {
            InitializeComponent();
            serial = port;
        }

On the Main Form

using System.IO.Ports;
SerialPort sp = new SerialPort();
private void servoToolStripMenuItem_Click(object sender, EventArgs e)
        {
            Servo SVR = new Servo(sp)
            {
                MdiParent = this
            };


            SVR.Show();
        }

 

So in the main form 'sp' is opened with the required com port, using the menu. Then it is passed to the other forms when they are opened, and set to another serial port object. So far this solution is working for me and i hope to keep it that way.

 

The only issue I can see being with this, is that it requires me to use the readline() and Writeline() method in every form and have the required exception handling every time. although after the trouble I had trying to get this to work in the first place, i really don't mind having the extra work. I could also see an error happening if you open the form before opening the Com port.

 

This afternoon we will be interfacing the MBed with the software to read the colour sensor and display the results, and i will be sitting down with the mechanical design team to work out the state machine i will need to implement on the FPGA. Ill try and post about them as well

  • in reply to michaelkellett

    We are using a Command/Response Protocol for working with the sensors, the rest of the forms will most likely just be sending data out, servo controls, we might implicate a error response if the command is out of range of the command.

     

    I had originally tried to have a command simply waiting on a input from the serial port so as to have a simple terminal application, but it just became too much of a pain in the backside, and was one of the things causing me stress when first trying to get the application running.

     

    At the moment I am happy with the way i have been able to implement it, or at least until it crashes for some random reason. If i build another c# program with multiple forms to control a serial port i may look to find another way.

  • Re the serial port.

     

    Normally you would only allow access to a hardware resource to just one module or object of your code.

     

    Any other forms or modules would only get access by calling that.

     

    The way I would design it is for the communications from PC to Mbed to use a strict "command/response" protocol. The PC will send commands and the Mbed will respond. The Mbed will never send a message except in response to a command and it will always respond within a defined (short) time. This allows you to use  blocking calls to a "sendcommand" method in your serial comms object (or module or task or whatever).

     

    If you are using threads in c# you can do better and allow many objects to access the "sendcommand" method simultaneously but it gets much more complicated because the serial comms object has to be able to queue the requests and send the responses to the right places.

     

    If more than one object has access to the hardware then there is no reasonable way of sharing the hardware (because you cant tell if some other object just sent a command and is waiting for  a reply.)

     

    C# is very big and complicated and offers many ways of dealing with asynchronous communications (that's where you send a command and don't wait for the answer) but you should be able to accomplish all you need with a much simpler (blocking) model.

     

    MK

  • in reply to DAB

    Biggest problem i had was just understanding object orientation in c#, and i was thinking that it should be more complex than it was. Though i was jumping up and down when it finally worked, and we managed to get the colour sensor working on the mbed, even with me not realizing that mbed uses c++ (though it was also c#) will post about it in a bit.

  • Nice update.

     

    When getting into projects with new tools and software, you always need to allocate some learning time.

    Often you discover that what the product promises is different from what the product can deliver.

     

    DAB