If statements

If statements have been implemented sufficiently to do the testing.

This also shows how I've made inputs and outputs be represented on the state or if blocks that they connect to.

Delete Marker

The above pictures demonstrate my working delete marker design. The first shows the markers linked in a random way and the second shows how once the delete marker crosses a link it removes it. I've also fixed a few other bugs over the last few days (a memory issue, the dtserver not being closed when the program stopped and a couple of others.) I've also started to formulate the vague structure of the report and am thinking about the if markers.

Further thoughts on if statements and deleting links

Here are some ideas of how to do the if statements and deleting links.

Ideas to do with the if statement and how to implement it

Ideas for how to do delete links between markers

Linking works now!!

I have got the linking working. You can now link any markers and place them wherever you like and they will be linked with a red line to demonstrate it.

How some of the markers will link together

I've scanned in some pictures I've drawn of how some of the markers will link to each other (graphing tools were difficult to get a good representation of what I wanted). 

This will mean breaking the marker types into which marker they represent. For instant marker types 1-5 could represent state markers, 6 the default marker, etc... I'll probably need to design new markers at some point (particularly in the case of the if markers) this would then make it more intuitive.

ASM detail & linking update

Quick update: In terms of linking I've got two markers linking but have a few bugs to resolve (for instance it is currently only linking one set of markers.

In terms of fleshing out the ASM charts that were posted last time. All three were taken from my logbook from last year. However only the final one (lift controller) has been taken straight and not simplified. This is because for testing purposes I want simple designs that demonstrate the capabilities not the the extras of a complicated ASM chart. The lift controller works on the basis that the lift is either at a floor or in a going up or down state. It's a simple controller so there are only 2 outputs of goUp or goDown. In the going up or going down states the correct output is emitted causing the lift to go up or down. The three ASM charts give a very simple idea of what is required to make a simple ASM chart. In the next post I will go into how I plan to design the TUI to make an ASM. 

ASM Charts

I'm still working on the linking. However I've drawn a few basic ASM charts to give an idea of the aim. They may be too large but give an idea of the different links/functions in an ASM chart

A very simple ASM chart consisting of only states (rectangles) and if blocks (diamonds)

An ASM originally based on the one above but includes conditional outputs (ovals)

A more complicated ASM chart made of states and if blocks

Progress

It is now functioning much better and the markers are now roughly proportional to reality and I've added a linking area below and a point above for linking. There are still a few glitches (one of the markers below isn't meant to be there!) but I'm working through them.

Event tracking. Implemented

The event tracking is now working and the client program is now displaying the markers (it is still a bit jerky and the session ids aren't great at the moment but it is all working)

I have also got the markers rotating so that the angle is used as well as location. The two obvious things to progress to are linking the markers and making the session ids work.

DTserver issues

Having adjusted the dtserver code considerably I attempted to run it but though it built and compiled it wouldn't run. Having made various different changes over a while I wanted to go back to the original code and just copy certain extra bits back in. However the SVN wouldn't let me go back (wouldn't clean up) so I downloaded the source files again. However unfortunately I cannot get these to both build. The core files build but the dtserver files won't because of the dtouchcore.lib file.

Event Tracking - updated

At the moment I've been looking at the dtServer. Problems have been:

• Difficult to get into the code
• Editing 3 bits of code that work together makes it difficult to test in stages
• Trying to keep the functionality of the original code as well as adding new functionality (backwards compatibility)

I was doing:

• Adding a variable to the fiducialdata type so that I knew whether it was being added, removed or moved
• Adding all the added, moved or removed markers to one eventtracked list
• Going through the eventtracked list and if the variable was added, removed or moved I'd emit <Added id=3...> or equivalent.

Having talked with Enrico I'm going to do:

• Instead of adding a variable I'll now make 3 lists. Each list will hold either added, removed or moved markers.
• These will then be sent along with the original marker information in the format <frame><marker>(original marker info)<added><marker>(added markers)</added>etc...</frame>
• In my client application I will then ignore all but the markers that are in added, removed or moved.

Editing DTserver

I've now started editing the dtServer code and am hoping to test the changes shortly. I will leave it largely the same but emit event tracked data. The main issue to resolve is the list holding the marker will now need an extra two variables in the form of type of marker (as well as id) and an action variable (NULL, MOVED, CREATED or DELETED)

Exams are over. Back to project!!

It's been a while and I haven't achieved much. I've looked into the code for the dtServer and have a rough idea of how bits of it work but haven't yet managed to implement event tracking properly. I did manage to get the DTServer automatically starting up when my application runs.

In the next few days I hope to really get to grips fully with the dtServer code and work out what needs to be done to implement event tracking.