Submitted by russj1975 on Wed, 01/19/2011 - 20:15
Posted in
Hi
My platform is ubuntu 10.10
I upgraded both the perl api to 0.03 and the slim version to 0.12 to fix a problem where i could not get get keyframes to work. However since upgrading, initially the script would take ages to communicate with the board and the script would not run until it was run a second time. Then the script ran and keyframing worked. Now its not possible to get a script to run and on the slim command line i'm getting Error: timeout reading from engine
if i enter commands individually it all works
i've tried going back to installing the version 0.02 of the api, though i'm not entirely sure how to remove the version 0.03
now when i run scripts after installing version two, the script does not behave - motor moves twice instead of once and camera does not fire.
I was starting to wonder if the arduino was fried but on my windows pc it all works fine, so it definitely my linux thats causing problems. How do i completely uninstall both perl modules from ubuntu?. I've removed libdevice-serialport-perl in synaptic package manager, and marked perl for reinstallation, tried again with the timelapse api 0.03, but no joy, it just plain refuses to run scripts and times out, however running commands manually is ok.
Can anyone help here?
Cheers
Russ
Russ, Don't go backwards!
Russ,
Don't go backwards! That won't fix your problem =) It will only create new ones as the releases you are working with are tied to each other, and there were changes to the protocol between versions.
Ok, so a timeout means that it is not getting a proper response from the engine, which likely means that there's some issue with how fast the commands are issued, and that is causing a problem down the line.
When you say that you run the commands manually, do you mean _all_ commands, or some of the commands manually? I.e., can you see which command is is timing out, and what the previous commands were before it?
There is likely one that is failing somewhere and causing the engine to stall for a while waiting for a response. I'd suspect that the most likely culprit in scripting mode is the first command sent after 'connect'. I'm thinking it may take some time before the serial port starts sending data, but behaves weird on linux and says its ready.
You shouldn't remove the packages unless you intend to fully remove it from your system and be done w/ that system. FWIW, you can do a 'make install' of any version of the timelapse module, and it will overwrite whatever is installed.
We need to find out which command is hanging it up, once we know that, we can fix it. (Or, at least work around it.) Unless you made changes to the firmware on the engine, the answer will lie in the script its self. "Initially the script would take ages to communicate with the board and the script would not run until it was run a second time" -- this is likely related to the same problem, but with better handling in the newer version.
(Yes, the timeouts are better behavior *grin* you had a major problem before, when you say it wouldn't start until it was run a second time -- this meant that either one command was taking way too long to complete, and it took a long time between completing and hitting the next steps in the buffer; or that one byte stream for a command resulted in an incomplete command and the buffer was off by a single byte until one or two more such off-states either resulted in being back on-track, or, more likely, the whole stream was off by one and its just random luck you got a start stream again.)
May be one rogue command with the wrong stream of data in the perl module, or just an odd sequence that we can code around.
!chris
Hi Since i was unsure what
Hi
Since i was unsure what damage i might have done to the linux OS install, i completely reinstalled it, then installed 0.03 api and 0.12 interface. Then at least i knew what i was working with and that it should be installed fine. There was no difference. One thing i did try, which you mention in your response, was to rearrange the order in the script so i was sending the motor instructions first rather than the camera instructions. I thought maybe if it got past the motor instructions at least i'd know it was something to do with the camera settings. It was still not working.
The timelapse engine code is untouched.
in terms of manual entries, this is what i have been entering. I can see the tx lights flashing as soon as i hit enter after each line, and the set of commands run for the allotted intervals.
> port /dev/ttyACM0
> connect
> set_camera exposure 500
> set_camera cycle 2
> set_camera shots 10
> set_camera on
> set_motor 0 steps 200
> set_motor 0 dir 0
> set_motor 0 enable on
> start
If i send the motor commands before the camera commands it still works. I have not tried entering the above along with action and keyframe entries, though having just tested the script with keyframes and actions commented out, it still stalls on the first command after connect. Suggesting that it is not keyframe commands causing this problem.
this is typicaly what i will see on screen:
[20] > load new.slim
Camera Settings
--> 2sec 150ms/200ms ON
[_openmoco_command] ERROR: Timeout Reading from engine (about 1 minute elapses before each new line)
[_openmoco_command] ERROR: Engine responded with error
[_openmoco_command] ERROR: Timeout Reading from engine
[_openmoco_command] ERROR: Engine responded with error
Motor Settings
--> Base Speed=20, Ramp=48, Dir=0
[_openmoco_command] ERROR: Timeout Reading from engine
[_openmoco_command] ERROR: Engine responded with error
[_openmoco_command] ERROR: Timeout Reading from engine
Actions
Keyframes
Executing Program = Complete in approx.2 minutes
Error: Could Not Start: [_openmoco_command] ERROR: Engine responded with error
i load the script again and it runs, though without keyframes it caries on shooting so i stop the program at the prompt. Load the script again and get the same errors as before.
The next time i ran it i had the above errors though they all said engine rseponded with error, this time though they appeared immediatley where as before it took a minute for each error line to appear, the camera was firing, but no motor movement.
Then it will run again, the camera and motor do what they should, though intermittently a shutter actuation will be missed, and it stops after 6 shots even though keyframes are commented out.
Interestingly the script runs to 6 shots and stops. 6 shots was the number i enntered when running the commands manually.
exit slim and restart. load the script and it stalls again.
As you can see there is no consistency in the response at all
Russ
Russ, That seems to indicate
Russ,
That seems to indicate that one command is not being received correctly, and it's messing all further ones up (the behavior you're showing is what would happen if an incomplete command was received, all future ones would behave strangely, but may get back in order for a brief period of time.) Actually, everything you're describing is just like one command is not completely received... It's usually the one right before the first timeout.
EDIT: I just replicated the behavior here, diagnosing =)
!c
Ok, there appears to be a
Ok, there appears to be a problem with sending commands too quickly. It's going to take me some time to get it fixed properly, but in the mean-time, here is a work-around:
edit openmoco-slim.pl
locate line #608, in the scr_load() function. It should look like this:
immediately after that line, add the following line:
Which will cause a 250mS delay between each command, which appears to work-around it for the time being.
!c
Hi Thanks for looking into it
Hi
Thanks for looking into it so quickly, and i'm pleased you were able to replicate it! Adding the line you suggest makes no difference for me i'm afraid, but what does work is changing it to this: sleep(0.5);
Sometimes, if i call the script again after its finished i get a timeout again, but restarting slim before running the script seems to be the way around it. entering the command stop after the script has run before running it again also seems to work. I'll probably increase the delay to 0.8 if i start having more issues, but at least its working now.
Once again, thanks for looking at this so quickly. I was reluctantly considering installing windows on my netbook to get this working. Thankfully that looks like its been avoided!
Russ