|
API Execute Problem
from United States [60 posts] |
11 year
|
The uploaded robo file when loaded directly into RR work fine. When the same file is read into my C++ program and transferred to RR via the execute API call does not load properly. Specifically, information for the AVI_WRITE module at the end is lost.
I wrote to console output the string just before it is used for the API execute and it is the same so there is no distortion in the reading process.
What I am doing is reading in snippets of RR pipeline XML and building a pipeline to execute in RR. As the tasks being performed by the robot change the pipeline is changed to only what is required.
If you delete the VA module the 'execute' works. But there are some other combinations of the modules between the VA and Write_AVI that also work.
I am using RR 2.50.17.
 program.robo
|
|
|
|
Carl from Your Country [1447 posts] |
11 year
|
Rud,
Its possible that something gets lost in the translation of loading he file in C++ and sending it to RR. Specifically, things like " should be translated into "e; before sending it to RR. Its important to realize that the XML format requires certain translations. Can you post your code here that you are using to transmit it? Are you running it through am XML escape routine?
STeven.
|
|
|
|
from United States [60 posts] |
11 year
|
I just remembered I am using an older version of the API so I did not have to change my C++ API. It may not have some of the XML changes you made back when I tried to load some CScript. Let me get back to you after I try this with the current API.
Rud
|
|
|
|
from United States [60 posts] |
11 year
|
I do have the current C++ files. The CPP is from 2/2/13.
I zipped my program and the robo files I am loading.
All I am doing is creating a list of file names containing snippets from robo files. The first file loaded contains a <header>. None of the other files contain that. Each file is read in turn and appended to the std::string. Then string.c_str() is passed to 'execute'. I see 'execute' calls 'escape'. Is that not sufficient or does something else have to be escaped?
What I want to have is a set of snippets that I can load as I begin processing certain goals with the robot. You know the SRR project I am working on. (...and boy is the pressure on with just a month to complete it!!!) Searching for samples requires a different pipeline than picking up a sample or depositing a sample.
I am trying to avoid having a big, complex, and fragile pipeline where parts are turned on and off with IF branches or by disabling modules. (The latter would be awfully fragile since there are certainly going to be multiple modules of the same type.)
There are some snippets in common, like the mosaic, some variable displays, and writing the AVI file to capture all the activities of the robot.
If you can suggest another way of handling this I am open to suggestions.
Rud
 RRFiles.zip
|
|
|
|
from United States [60 posts] |
11 year
|
Just to add something more...
I changed my process to write the pipeline script to a file and use loadProgram to load that file. It works as expected so the snippets are valid.
The problem is it can take up to a second to load the new file which is longer than I can accept.
I would really like to able to update the pipeline using the XML process. What this latest test shows me is even if I wrote each of my pipelines to separate robo files they would take overly long to load.
Rud
|
|
|
|
Carl from Your Country [1447 posts] |
11 year
|
Rud,
Thanks for the test files. That helped determine the issue.
The problem turns out to be a simple one, the created XML string was just too big to be sent using the current API routines. It uses a 4096 sized buffer to escape out the string before sending it out. Increasing the buffer size seems to fix that problem.
We've updated the API.zip file to include those changes. You only need to replace RR_API.cpp and RR_API.h in your files. That should do it.
STeven.
|
|
|
|
from United States [60 posts] |
11 year
|
That did fix it.
I am kind of kicking myself because I overran the buffer doing something else and actually doubled its size to fix that problem. I remember we encountered that problem before, also.
I have an update request for Mosaic: add the common 16:9 image formats to the drop down list.
|
|
|
|
Carl from Your Country [1447 posts] |
11 year
|
We added the 16:9 formats to the Mosaic module ... but you can also just type in the sizes too. The listed formats are just a shortcut.
STeven.
|
|
|
|
from United States [60 posts] |
11 year
|
|
Thanks for that change. I setup Mosaic quite frequently in my testing so having the formats in there makes it easier.
|
|
This Thread