Inkscape SVG file question and some EBB command quesitons

[Jacob Grunwald]

I’m trying to port the EggBot code to a different microcontroller, which is going fairly well. I’ve gotten the EggBot extension to recognize my board by telling it to provide EBBmimic when it receives the “vr” command, and almost all of the command processing is working well. The query button and query pen commands are not though. For the button command specifically I looked through the source code for the EBB v2.3 and see that upon receiving a ‘QB’ command it sends back the button state, where 0 is unpressed, followed by an ack. I am sending the same thing, however I don’t think the Inkscape extension is reading in the button state from my board. It is always seeing the button as pressed regardless of whether it has been pressed or not which leads me to believe the python script isn’t reading the data. I compared the outputs from both my board and the EBB to see if there was any difference in the hex being sent, but have got nothing. This lead me to believe that the issue was probably in the communication speed that my board is communicating at, or possibly in how the python extension is reading the data. So I decided to look at the python.

Right now I have the files in the inkscape_driver folder from the github repo here: https://github.com/evil-mad/EggBot in a visual studio project using python 2.7. The script runs, but only because I changed the self.svg_file line in the affect function of inkex.py to be a hard coded file name rather than having it pull it’s information from inkscape. This is working ok as well. I am seeing that the svg file is being read in properly. I am not sure if it is being parsed properly though. From what I understand, the parsing routine breaks up the svg file based on tags within the tags. The program then takes however many of these it finds and runs them through a comparison routine to see if the tag is either ‘eggbot’ or something like http://www.w3.org/2000/svg eggbot. That tag isn’t anywhere in the svg file though. It isn’t in any of the example inkscape svg files either.

Is the svg file modified in any way when it is output from inkscape to the python script? If so, are certain tags in the svg converted into ‘eggbot’ tags?

Any ideas as to why the data the ‘QB’ is sending isn’t being read by the Inkscape extension even though it is identical to the information being sent by the EBB?

As a side note, in the latest release of the EggBot drivers from github, the inkex.py file that is used in the actual extension is different than the one that is in the inkscape_driver folder. I’m not sure if you guys control that particular file or if Inkscape updates it with newer versions of Inkscape.

[Windell Oskay]

The svg file is directly “handed” to the python script. It is not modified, so far as I know.

If the QB command works differently than on our hardware, there must be some difference in how it’s implemented. If it was genuinely identical, it would work identically.

Can you please point out the actual location this copy of inkex.py is located on github? I didn’t see it in a first pass.

[Jacob Grunwald]

Thanks for the quick response!

My mistake about the inkex.py file. I must have added it to the folder a long time ago and just forgot that it wasn’t a part of the github download. Apologies.

When I said the QB information was identical, I meant what it is sending. The ASCII is identical. Your response makes me think I have a timing issue of some sort.

[Windell Oskay]

There is not separate timing used for the QB command– if timing is working correctly for other commands, it should work there. You might try checking the EBB Command Set Documentation as your reference on what exact characters it should send back.

[Jacob Grunwald]


That is a good point. I checked the documentation, and am pretty certain I am printing the same thing.Here is the code that handles QB as well as what prints the ack. Button pushed here is a uint8 that is 0 until the button is pressed. When the button is pressed I have an interrupt that toggles it to 1. I’ve checked that that part works using RealTerm. SIMPLE_ASCII_INT_CONVERSION is 48 which is 0 in ASCII.

[Windell Oskay]

I don’t know enough about the environment that you’re working with here to make any informed guesses as to what the issue is. However, my instinct would be that a function named something like “writeLine” (as opposed to “write”) would have a built-in linefeed of some sort, which may not work well with all of the explicitly written line terminators that you have added.

[lawrence0]

To be honest, it is really hard to say.

[Author]

Posts