Re: [Emc-users] How Fast Are Pythons
Kirk Wallace wrote:
>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 ~
>
>
or
FUNCTION(_) {
out = (in0 == in1);
}
The result is a boolean, after all :)
This also eliminates potential problems with false being 0, nonzero, 1,
not 1, -1, etc.
I think you can install a comp with an incantation like comp --install
mycomp.comp, but don't quote me on that. Otherwise, a recompile should
pick up the new comp if it's in the right directory (hal/components is
one such directory).
- 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
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
Re: [Emc-users] How Fast Are Pythons
On Thu, 2007-08-23 at 18:13 -0400, Stephen Wille Padnos wrote: > 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 ... snip > >>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 ... snip > >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. This ( http://linuxcnc.org/docs/html/man/man9/weighted_sum.9.html ) weighted sum is great. It takes a least half my lines of script (here in M101 by the way: http://www.wallacecompany.com/cnc_lathe/HNC/emc2/nc_files/ ) and puts it in realtime (?) HAL. > 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, CCW only > 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. Similar to and2.comp only start by defining the I/O pins to be s32 instead of bit? More homework. > 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 When I see the word "index", I think we still might be misunderstanding each other. Right now, I am using an indexing routine to cope with userspace timing issues (or some other problem). Which is like controlling the turning of a bicycle wheel by putting a stick between each spoke until I get to the position I want. Using the information you have given me, I am going to spin the wheel and at just the right time jamb the stick in and stop it right on the spot I want. Once I get the turret spinning, I'll count the spokes with weighted_sum and jamb the stick with and8.comp(new). > (AND and NOT are both HAL components already, and there are other logic > components) I used NOT to flip-flop my high and low clutch pins. > 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 I write a very small C program about once a year, and almost have to start at "Hello World", but I think I am going to like this comp tool thing. 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: > 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(?). > 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? It is not a matter of speed. Just about _any_ programming language can do what you want in 30ms (or even 30uS) as long as it is actually running. But a user space program isn't always running. There are dozens of things going on in your PC, and Linux can and does suspend any user space program to let other things run. Most of the time it is only for a fraction of a millisecond, or a few milliseconds, but there are NO guarantees for user space programs. If you need measure or control things on a time scale that is less than seconds, you _really_ should be doing it using realtime code. That can mean classicladder, or realtime HAL components, or EMC itself. Steven has suggested ways to do it with HAL components, but I'd really recommend classicladder. PLCs were invented to do _exactly_ what you are trying to do. Why reinvent something? Regards, John Kasunich - 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
>>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
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
> 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
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
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
[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
