POV / Propellor Display - Part1
Posted: Wed Jun 17, 2015 7:10 pm
Hello All,
I think I may finally be onto something with the mechanics for my hobby propeller display project so I have started to create a Flowcode 6 component to allow me to simulate and develop better firmware.
I am sharing here so that others may benefit from being able to create components with simulations.
Previous working prototype using Flowcode 4 for dsPIC.
[/youtube]
To start with I have created the basis for the simulation which is auto generating the panel objects based on the users property selection.
First I made a few properties to allow the user to change things, number of leds, number of segments, I/O etc. I also included properties to allow the simulation to try and replicate the physical display as much as possible such as LED size, pitch and spacing from the central pivot.
Once the properties were in place I went to the events tab of the project explorer and added a macro for the component -> property event. This macro then fires whenever any of the property values are changed.
Inside the property event macro I added calculations to allow the various properties to correctly calculate some helpful values that might help the end user.
The next job was to create the objects on which to host the simulation. I started by dragging a sphere object onto the panel, giving it a suitable name and then copy/pasting the object on the panel. I selected both objects and clicked the group button to create a new group which I also renamed with something sensible. I then double clicked the original object and changed the visible property to false.
The Sim_DestroyLEDs macro uses the Tree simulation API commands to move through the components on the panel in the group. It deletes all the objects inside the group except for the none visible template object by comparing the objects name with a hardcoded value.
The Sim_BuildDisplay macro takes the position of the none visible template object and then draws the LEDs outward from the center a segment at a time. We do this by working out the vector based on the number of segments vs the current segment index and then moving the position object by the spacing property multiplied by the vector.
Calls to the Destroy and Build macros were then added to the property change event as well as a simulation API call to resize the template object.
Thoughts so far...
The LEDs take a long time to generate if a high number of segments is used. I think on my display I used between 120 and 360 segments so that's lots of pixels to create and maintain. This means the simulation will likely run slow too. You may get a popup saying that the event macro is taking a long time, simply click no and the full display should be drawn eventually.
Therefore I wonder if I can change things up so that the number of segments is automatically reduced as you get closer to the center of the display. This would certainly provide a more efficient way of doing things and should also look better on the physical display. The downside to this is the routine to clock out the data to the LEDs would become more complex and ideally this needs to be as fast as possible to maintain a nice lit pixel and to allow some room for the main application to run.
Here is the component source so far.
If anyone wants to know more about creating components then these videos might help get you started.
https://www.youtube.com/watch?v=O41_diP ... EGDynfBCsf
https://www.youtube.com/watch?v=RWZcctF ... Fvp-GxBLgc
More to come soon...
I think I may finally be onto something with the mechanics for my hobby propeller display project so I have started to create a Flowcode 6 component to allow me to simulate and develop better firmware.
I am sharing here so that others may benefit from being able to create components with simulations.
Previous working prototype using Flowcode 4 for dsPIC.
[/youtube]
To start with I have created the basis for the simulation which is auto generating the panel objects based on the users property selection.
First I made a few properties to allow the user to change things, number of leds, number of segments, I/O etc. I also included properties to allow the simulation to try and replicate the physical display as much as possible such as LED size, pitch and spacing from the central pivot.
Once the properties were in place I went to the events tab of the project explorer and added a macro for the component -> property event. This macro then fires whenever any of the property values are changed.
Inside the property event macro I added calculations to allow the various properties to correctly calculate some helpful values that might help the end user.
The next job was to create the objects on which to host the simulation. I started by dragging a sphere object onto the panel, giving it a suitable name and then copy/pasting the object on the panel. I selected both objects and clicked the group button to create a new group which I also renamed with something sensible. I then double clicked the original object and changed the visible property to false.
The Sim_DestroyLEDs macro uses the Tree simulation API commands to move through the components on the panel in the group. It deletes all the objects inside the group except for the none visible template object by comparing the objects name with a hardcoded value.
The Sim_BuildDisplay macro takes the position of the none visible template object and then draws the LEDs outward from the center a segment at a time. We do this by working out the vector based on the number of segments vs the current segment index and then moving the position object by the spacing property multiplied by the vector.
Calls to the Destroy and Build macros were then added to the property change event as well as a simulation API call to resize the template object.
Thoughts so far...
The LEDs take a long time to generate if a high number of segments is used. I think on my display I used between 120 and 360 segments so that's lots of pixels to create and maintain. This means the simulation will likely run slow too. You may get a popup saying that the event macro is taking a long time, simply click no and the full display should be drawn eventually.
Therefore I wonder if I can change things up so that the number of segments is automatically reduced as you get closer to the center of the display. This would certainly provide a more efficient way of doing things and should also look better on the physical display. The downside to this is the routine to clock out the data to the LEDs would become more complex and ideally this needs to be as fast as possible to maintain a nice lit pixel and to allow some room for the main application to run.
Here is the component source so far.
If anyone wants to know more about creating components then these videos might help get you started.
https://www.youtube.com/watch?v=O41_diP ... EGDynfBCsf
https://www.youtube.com/watch?v=RWZcctF ... Fvp-GxBLgc
More to come soon...