Re: [Emc-users] How Fast Are Pythons
On Thu, 2007-08-23 at 18:13 -0400, Stephen Wille Padnos wrote:
... snip
Just using wsum made a big difference in the shell script. I was
consistently just one tool position off with the rotate direct to
station routine, and it only gets better from here.
If the
turret can't move in both directions, then you can do the whole thing
with HAL components - no classicladder needed. You'll have to write a
simple component to compare two s32 numbers (strange but true - there's
an 8-bit pattern match with cascade input component, but no integer
comparison :) ) Look at something like xor2.comp for an example of a
simple .comp component.
Like this?
~ s32equal.comp ~
component s32equal Check if two s32's are equal;
pin in s32 in0;
pin in s32 in1;
pin out bit out;
function _ nofp;
license GPL;
;;
FUNCTION(_) {
if (in0 == in1)
out = 0;
else
out = 1;
}
~ s32equal.comp ~
then recompile EMC or just the component?
use debounce / weighted_sum to get a stable position reading (current_tool)
use tool_change AND NOT (requested_tool == current_tool) to enable the
turret to index
(AND and NOT are both HAL components already, and there are other logic
components)
I think that's about it. Another option is to just write a .comp to do
it all - take in 4 bits, the requested tool number, and the
tool-prep/tool-change signals, output tool_prepped/tool_changed and
turret controls.
Then forget the M101 and tie into the pins used by M6, as nature had
intended.
The comp preprocessor really helps make this kind of
HAL component easy to write.
- Steve
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] How Fast Are Pythons
My first pass on getting my lathe turret working went okay. It turns out that shell scripts are way too slow for what I was trying to do. The plan was to, using an M101 script, energize the rotator solenoid, which raises the turret table and starts it rotating. I then monitor the four bit binary position input for a match between the requested tool position and the current tool position. As soon as a match occurs, I activate the stop dog solenoid, wait for the table to settle, deactivate the rotator solenoid, wait for the table to descend and lock, and finally deactivate the stop solenoid. On most of the steps, the table would rotate two or more positions before an action took place. So, I went back to my pre-feedback plan. I setup the script to only rotate the table one position - rotate, sleep .1, stop, sleep .1, de-rotate, sleep .1, de-stop, check for match, repeat till done or tender. It actually works pretty well. The problem is that scripts are interpreted or compiled while the program executes. Python is the same way, I believe, so it would have the same speed issues? I may convert my script to C and then call the C program from an M101 script. Kirk Wallace - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] How Fast Are Pythons
This really sounds like a perfect job for classicladder. If you arent
interested in learning ladder logic, then writing a custom hal component
might be easier, since you seem comfortable with C. I think the issue here
is that your script is not running realtime, and so the timing is off.
As you can see, sleep isn't always real accurate:
$ firefox; time sleep 0.1
real0m0.313s
A C or python program would have the same problem:
#include unistd.h
int main(){ usleep(10); }
$time ./test
real0m0.151s
import time
time.sleep(0.1)
$time python test.py
real0m0.140s
you could also try running your script with a higher priority. (renice)
btw you are actually having a problem right? or are you just informing us
of what you did?
--fenn
My first pass on getting my lathe turret working went okay. It turns out
that shell scripts are way too slow for what I was trying to do.
The plan was to, using an M101 script, energize the rotator solenoid,
which raises the turret table and starts it rotating. I then monitor the
four bit binary position input for a match between the requested tool
position and the current tool position. As soon as a match occurs, I
activate the stop dog solenoid, wait for the table to settle, deactivate
the rotator solenoid, wait for the table to descend and lock, and
finally deactivate the stop solenoid. On most of the steps, the table
would rotate two or more positions before an action took place.
So, I went back to my pre-feedback plan. I setup the script to only
rotate the table one position - rotate, sleep .1, stop, sleep .1,
de-rotate, sleep .1, de-stop, check for match, repeat till done or
tender. It actually works pretty well.
The problem is that scripts are interpreted or compiled while the
program executes. Python is the same way, I believe, so it would have
the same speed issues?
I may convert my script to C and then call the C program from an M101
script.
Kirk Wallace
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] How Fast Are Pythons
On Thu, 2007-08-23 at 17:24 +, ben lipkowitz wrote:
This really sounds like a perfect job for classicladder. If you arent
interested in learning ladder logic, then writing a custom hal component
might be easier, since you seem comfortable with C. I think the issue here
is that your script is not running realtime, and so the timing is off.
The turret rotates at about one revolution per second, giving 125ms per
tool position. My guess is that if I can process four or five position
samples in that time, it should work. The problem is that, I think it is
taking around 200ms to do it. If I were using a precompiled program, I
think I should be able to do tens or hundreds of samples per position
even in userspace(?).
As you can see, sleep isn't always real accurate:
It should be accurate enough were I would like to use it - that being,
just after solenoid commands to let the mechanical parts to come to
equilibrium. Originally, I had no sleep between rotate, sample,
activate stop. After the stop, sleeps for the park procedure were all
minimum times.
$ firefox; time sleep 0.1
real0m0.313s
A C or python program would have the same problem:
#include unistd.h
int main(){ usleep(10); }
$time ./test
real0m0.151s
import time
time.sleep(0.1)
$time python test.py
real0m0.140s
you could also try running your script with a higher priority. (renice)
btw you are actually having a problem right? or are you just informing us
of what you did?
--fenn
I still have a problem, sort of. I had to fall back on a less desirable
method to get it to work. It now does a complete single tool position
change using only solenoid commands and sleep - no position processing.
After the turret parks, I sample the position and if the requested
position and current position don't match, I have it jump to the next
position, park and test again until I get a match. What I would prefer,
is to process the location during rotation and only stop and park after
I get a match.
Bottom line (I think), how can I get enough processing done in 30ms to
decode and match two (32 bit unsigned?) words?
(By the way, this is how I decode the position bits:
halcmd show inputs
grep and cut
change each bit, ones, twos, fours, eights from T or F to 1 or 0
current_tool=$((ones+(2*twos)+(4*fours)+(8*eights)))
I visit Grandma on the way)
Kirk Wallace
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] How Fast Are Pythons
Kirk Wallace wrote:
On Thu, 2007-08-23 at 17:24 +, ben lipkowitz wrote:
This really sounds like a perfect job for classicladder. If you arent
interested in learning ladder logic, then writing a custom hal component
might be easier, since you seem comfortable with C. I think the issue here
is that your script is not running realtime, and so the timing is off.
The turret rotates at about one revolution per second, giving 125ms per
tool position. My guess is that if I can process four or five position
samples in that time, it should work. The problem is that, I think it is
taking around 200ms to do it. If I were using a precompiled program, I
think I should be able to do tens or hundreds of samples per position
even in userspace(?).
As you can see, sleep isn't always real accurate:
It should be accurate enough were I would like to use it - that being,
just after solenoid commands to let the mechanical parts to come to
equilibrium. Originally, I had no sleep between rotate, sample,
activate stop. After the stop, sleeps for the park procedure were all
minimum times.
$ firefox; time sleep 0.1
real0m0.313s
A C or python program would have the same problem:
#include unistd.h
int main(){ usleep(10); }
$time ./test
real0m0.151s
import time
time.sleep(0.1)
$time python test.py
real0m0.140s
you could also try running your script with a higher priority. (renice)
btw you are actually having a problem right? or are you just informing us
of what you did?
--fenn
I still have a problem, sort of. I had to fall back on a less desirable
method to get it to work. It now does a complete single tool position
change using only solenoid commands and sleep - no position processing.
After the turret parks, I sample the position and if the requested
position and current position don't match, I have it jump to the next
position, park and test again until I get a match. What I would prefer,
is to process the location during rotation and only stop and park after
I get a match.
Bottom line (I think), how can I get enough processing done in 30ms to
decode and match two (32 bit unsigned?) words?
(By the way, this is how I decode the position bits:
halcmd show inputs
grep and cut
change each bit, ones, twos, fours, eights from T or F to 1 or 0
current_tool=$((ones+(2*twos)+(4*fours)+(8*eights)))
I visit Grandma on the way)
Kirk Wallace
OK - I see some room for improvement here :)
First, there's a HAL component called weighted_sum - use that to
generate positions from the input bits. You may want to stick a
debounce on the input bits as well - they're bound to be a little noisy.
There's also a component called modmath - if the turret can be indexed
in both directions, you can use this component to tell you which way is
the shortest from the current position to the requested one. If the
turret can't move in both directions, then you can do the whole thing
with HAL components - no classicladder needed. You'll have to write a
simple component to compare two s32 numbers (strange but true - there's
an 8-bit pattern match with cascade input component, but no integer
comparison :) ) Look at something like xor2.comp for an example of a
simple .comp component.
use debounce / weighted_sum to get a stable position reading (current_tool)
use tool_change AND NOT (requested_tool == current_tool) to enable the
turret to index
(AND and NOT are both HAL components already, and there are other logic
components)
I think that's about it. Another option is to just write a .comp to do
it all - take in 4 bits, the requested tool number, and the
tool-prep/tool-change signals, output tool_prepped/tool_changed and
turret controls. The comp preprocessor really helps make this kind of
HAL component easy to write.
- Steve
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
