Making an entity blink with a very precise delay time
Steve Doman
In the function defined below, an entity
can be displayed to "blink" on and off. In
order for the cad operator to see this happen
a delay has to be included between the on
and off modes.
When I first wrote this function, I used the
AutoCAD command "DELAY" to control the amount of
time between on and off: (command "delay" someinteger)
However, the delay was painfully too long even when
using the lowest possible value for the time argument, 1.
The time argument is supposed to be in milliseconds but
it seems more like in one second increments.
My solution was to skip the use of DELAY, and instead
use a simple interation that does nothing but kill time:
(repeat someinteger (princ))
The drawback to this design, is that different
PC's run at different speeds and therefore this
blink function will not blink at the same rate
on all machines.
Does anyone have a better solution? Or perhaps
some way to cause a small, precisely controlled delay
that would run at the same rate on any machine?
;; Function: Blink
;;
;; Makes an entity blink on and off
;;
;; Requires three arguments:
;;
;; ename is an entity name
;; count is the number of times to blink (integer)
;; dlay amount of time between blinks (integer)
;;
;;
(defun Blink (ename count dlay)
(repeat count
(redraw ename 2)
(repeat dlay (princ))
(redraw ename 1)
(repeat dlay (princ))
)
)
;;
Thanks,
Steve Doman
Stephen L. Bowen
If you are simply wanting to have a program "wait" a
specified amount of time, then I suggest the following. At
the point in the program you want to "wait", save the value
of the system variable "CDATE" to a variable.
(setq tm (getvar "cdate"))
Then add the amount of time you want the program to wait.
(setq tm (+ tm 120))
The start a while loop that checks the current value of CDATE
and while it is less than the variable TM, continue to loop.
(while (< (getvar "cdate") tm)
nil
)
When the amount of time you added has expired, the loop will
end.
Good Luck,
Stephen L. Bowen
President, PowerLISP Solutions
www.powerlisp.com
Steve Doman
Thanks for the reply and I found your program very interesting. This approach
will not work for what I am trying to do however. What I have is an AutoLISP
program that joins lines together. For example if there are two horizontal line
segments, end to end, it will convert them into one line.
The problem is, if the lines are the same color, there is no indication that the
program has worked. For example if the user runs the program and selects two
white lines that are end to end, the program converts them into one line, and
this new line looks the same on screen as the two lines did before converting.
So, in order to give the user some feedback that the program worked, I would
like to make the new line blink. Now, if the blink is too long, it becomes
annoying. If it is to short, the user cannot perceive the blink.
Using (command "delay" number) does not allow for a short enough time period to
avoid become an annoyance in this situation. I have experimented with the delay
argument using your program, just as a test, and found that I could not perceive
any difference in delay time when the delay argument was 1 or 1000! I wonder if
this is some bug in the delay command.
Hence, I came up with creating a delay by interation or looping. The blink
function in my original post has three repeat functions. The two inner repeat
functions just do nothing but repeat (princ) as a method of using up some time
between on and off display of the entity. The outer repeat function is used to
make the entity blink repeatedly.
This interation method however, is a function of processor speed and therefore,
does not run at the same rate on say a P100 Vs. a PII-400 PC. It does however,
allow for a very short, carefully controlled time delay. My problem is, how to
adjust for different machines short of having the user set the delay values. (Or
maybe I'll just dump the whole idea and not give the user feedback).
Hope that makes sense.
Regards,
Steve Doman
-----
Jose Luis Menegotto wrote...
>Hello Steve
>
>I use to blink virtual vectors generated by the (grvecs) function over the
>entities I want to watch. In this example all the insertions in a drawing
>are sorrounded by a square which change your color from red to yellow with a
>second of delay.
>
>This works fine to me. You can change the filter selection (ssget) in order
>to blink other types of entities.
>
>I hope this help.
>
>José Luis Menegotto
>www.trip.com.br/arqdigital
>
Steve Doman
Cool! What a great idea. I'm going to experiment with this. I think this
should work across different machine processing speeds too.
Thanks a billion,
Steve Doman
----
Stephen L. Bowen wrote...
Steve Doman
O.K. Here's what I have come up with so far. I took your idea, plus what I
could learn from the help docs, and came up with this. I am trying to make the
entity just slightly flash or flicker. Just enough of twitch to catch the
user's eye, yet not cause annoying delay. I would appreciate getting some
feedback from people out there as to whether this runs too fast or too slow on
their system. I am testing on a P100 (don't laugh, it's my home PC).
;; Function: Blink
;;
;; Makes an entity blink on and off
;;
;; Requires three arguments:
;;
;; ename is an entity name
;; count is the number of times to blink (integer)
;; delay amount of time between blinks (real)
;;
;; Suggested argument values:
;; count = [1,2,3]
;; delay = [0.1-1]
;;
(defun Blink (ename count delay / msec )
;local function
(defun milliseconds ( / temp)
(setq temp (getvar "DATE"))
(* 86400.0 1000.0 (- temp (fix temp )))
)
(repeat count
(redraw ename 2) ;hide
(setq msec (milliseconds))
(while ( < (milliseconds) (+ msec delay )) (princ) )
(redraw ename 1) ;show
(setq msec (milliseconds))
(while ( < (milliseconds) (+ msec delay delay)) (princ) )
)
)
;;
;; Here is a quick and dirty front end to help test
;;
(defun c:blinktest ()
;blink ename count delay
(blink (car(entsel "\nSelect an entity to blink: ")) 2 0.5)
(princ)
)
;;
Thanks for the help,
Steve Doman
Tony Tanzillo
for this (and, adding 120 to it as per Stephen's
example will cause your program to wait roughly
4.0 months <g>).
You use the DATE system variable which represents
time in decimal days. In any case, you will never
get a precise delay time using a loop in AutoLISP,
since the delay will always be an even multiple of
the time required to execute the loop, plus return
to the caller. So the best you can hope for is a
delay function that will wait at least the amount
of time you want, or slighly longer.
This function will delay execution for at least
the specified number of seconds, but is not too
reliable for delays < 1 second, and is subject
to the aforementioned caveat.
(defun wait (seconds / stop)
(setq stop (+ (getvar "DATE")
(/ seconds 86400.0)))
(while (> stop (getvar "DATE")))
)
Steve Doman wrote:
>
> Cool! What a great idea.
--
/*********************************************************/
/* Tony Tanzillo Design Automation Consulting */
/* Programming & Customization for AutoCAD & Compatibles */
/* ----------------------------------------------------- */
/* tony.t...@worldnet.att.net */
/* http://ourworld.compuserve.com/homepages/tonyt */
/*********************************************************/
Steve Doman
Thanks for your help. I did catch the CDATE error too. I think Stephen was
just working off the top of his head. No problem and I appreciated his idea.
Anyhow, I rewrote my blink function inserting your wait function as the timer.
This works good too, but I did have to make one little tweak. I don't know way
this works, but I inserted a (princ) statement inside the while loop. Without
it, the blink just doesn't look right. It just sorta makes a weird clumsy on
and off. With the (princ) statement, it sorta twinkles. However, I have no
idea if this fine-tuned timed function will work the same on all machines. I
doubt it.
So...question:
Can I safely assume that this blink will work at the same speed on all machines?
If I can't get this to work the same on all machines, I'll either have to drop
the feature of provide code in the main program to prompt the user to select
their own personal rate (preference). On top of all that, I'll then need to
save that setting data somewhere, somehow, so the program will use the settings
as defaults. I was thinking of something like: (setcfg
"AppData/Doman:UnBreak/blinkdelay" delay). Any opinions on this? :)
;; Function: Blink
;;
;; Makes an entity blink on and off
;;
;; Requires three arguments:
;;
;; ename is an entity name
;; count is the number of times to blink (integer)
;; delay amount of time between blinks (real)
;;
;; Suggested argument values:
;; count = [1,2,3]
;; delay = [0.01-1]
;;
(defun Blink (ename count delay / msec wait)
;local function
(defun wait (seconds / stop)
(setq stop (+ (getvar "DATE")
(/ seconds 86400.0)))
(while (> stop (getvar "DATE"))(princ)) ; <-- added a (princ)
)
;;
;;
(repeat count
(redraw ename 2) ;hide
(wait delay)
(redraw ename 1) ;show
(wait delay)
)
)
;;
;;
;; Here is a quickie front end to help test
;;
(defun c:blinktest ( / ename )
(setq ename (car(entsel "\nSelect an entity to blink: ")))
;blink ename count delay
(if ename (blink ename 2 0.1))
(princ)
)
;;
Thanks again for the help,
Steve Doman
-----
Tony Tanzillo wrote...
Dave Jones
<ste...@onlinemac.com> wrote:
>Stephen and all,
>
>O.K. Here's what I have come up with so far. I took your idea, plus what I
>could learn from the help docs, and came up with this. I am trying to make the
>entity just slightly flash or flicker. Just enough of twitch to catch the
>user's eye, yet not cause annoying delay. I would appreciate getting some
>feedback from people out there as to whether this runs too fast or too slow on
>their system. I am testing on a P100 (don't laugh, it's my home PC).
>
(snip)
Blinktest Results, 11-29-98 7:56am
Non-Scientific, Uncontrolled, Totally Biased Report :)
P100, P133, PII400 used to run blinktest.lsp
if there's any difference in the blink speed on the three machines,
I'm not able to discern it. I think you've got it!
Dave
Tony Tanzillo
solution to your problem. On my system, it doesn't
work very well at all. I see nothing but a blank
screen.
Why don't you just draw "grips" the endpoints of the
lines rather than blinking them?
Steve Doman wrote:
>
> So...question:
>
> Can I safely assume that this blink will work at the same speed on all machines?
>
> If I can't get this to work the same on all machines, I'll either have to drop
> the feature of provide code in the main program to prompt the user to select
> their own personal rate (preference). On top of all that, I'll then need to
> save that setting data somewhere, somehow, so the program will use the settings
> as defaults. I was thinking of something like: (setcfg
> "AppData/Doman:UnBreak/blinkdelay" delay). Any opinions on this? :)
>
--
Steve Doman
Gee, you have pretty much covered the whole spectrum of current machines, thank
you! Which reminds me of a Cobol programmer that I used to commute to Portland
with while I was going to PSU. She would compile code on one machine, and while
that was running she would edit the code on another, and had yet a third machine
for testing the newly compiled code. Running three PC's at a time really took
a toll on her patience. When we came to a stoplight and had to wait a long
time, she would nervously shake the leg that was holding the brake pedal down
and make the whole car shake. One time, when she was doing this shake thing
real bad, I told her: "Press space bar to continue..." . This has nothing to do
with you of course, it was the three PC's that reminded me of her.
Thanks for the feedback!
Regards,
Steve Doman
-----
Dave Jones wrote...
Steve Doman
>Personally, I don't think blinking objects is a good
>solution to your problem. On my system, it doesn't
>work very well at all. I see nothing but a blank
>screen.
Sorry, I don't understand. Are you saying that when you select an entity to
blink, it just disappears and doesn't redraw?
>Why don't you just draw "grips" the endpoints of the
>lines rather than blinking them?
Now that's an interesting idea! I'll have to play around with that and see what
happens.
Thanks,
Steve Doman
Bill Farmer
have them highlighted after the join operation if the join operation was
successful and not if unsuccessful. Just throwing in my $0.005 worth. I've
got a program that I've been using for years to join lines (heal, complete,
or whatever term you choose) & arcs into circles. The command line informs
you of a successful operation on lines. There is no need for it when
converting arcs into circles.
Bill
Jose Luis Menegotto wrote in message
<73rqi0$gq...@adesknews2.autodesk.com>...
>Hello Steve
>
>I think about your problem and a would suggest you to try this method:
>
>1- when the operator select the first line to join this segment become
>+ACI-red+ACI-.
>2- when the second line were selected the new line (line1 +- line2) become
>blue and remains blue waiting for other operation.
>
>Advantage:
>You don't think in terms of time. You get visual control all the time. The
>operator see what he has already done. A redraw command at the end will
>clear all the virtual vectors.
>
>Disadvantage
>You need to be careful on what color you use in this operation, this means,
>you need to control the color of the virtual vector in order to be
different
>of the real vector (to do that you have to know the color of the real
vector
>capturing the name of layer (code 8) and searching on the layer table for
>the correspondent color. If the entity to join is not bylayer color
property
>then you can capture the color with a code 62.
>
>
>
>Regards
>Jose Luis Menegotto
>
>
>
Steve Doman
Thanks for the reply and interesting, novel idea. I'm sending you a copy of the
program I'm working on so you can see what's going on. Anybody else who wants a
copy just email me.
Thanks,
Steve Doman
----
Jose Luis Menegotto wrote ...
>Hello Steve
>
>I think about your problem and a would suggest you to try this method:
>
>1- when the operator select the first line to join this segment become
>"red".
>2- when the second line were selected the new line (line1 + line2) become
>blue and remains blue waiting for other operation.
>
(clip)
Steve Doman
Your $0.005 worth is always welcomed. So, are you saying that after the join
operation, the lines are left in a highlighted state? Meaning that the user
needs to do a redraw to clear the highlight?
The first glue/join program I used was back with Release 9 ( anybody remember
KAST menu from KETIV? ). The program I am working on today is just an
improvement of this old idea. I had downloaded every glue/join program I could
find on the Internet. All of them failed to weed out noncollinear lines which
was my most basic requirement ('cause I do CNC drawings and must). I also
needed a glue/join program that works CORRECTLY on 3d lines, a nice touch when
working in paperspace mviews. So, after wasting a lot of time downloading and
testing everything I could find in the whole wide world, I thought I would just
write the darn program myself and then post it somewhere on the Internet for
other to use free. It has been quite the learning experience and I must admit I
was/am over my head. I have yet to add the arc join code; but that's planned
however.
Thanks,
Steve Doman
Bill Farmer wrote ...
Dave Jones
awhile after graduating from US Grant on NE 33rd before heading south
to the SF bay area...(1967...yes, I am old :)
Dave
ps: I didn't run blinktest.lsp on the P100, as you had done so
already, nor the 386SX33 or 486DX66 as I didn't want to fire them up.
Can you tell I'm a puter pack rat :)
Tony Tanzillo
>
> Tony Tanzillo wrote...
> >Personally, I don't think blinking objects is a good
> >solution to your problem. On my system, it doesn't
> >work very well at all. I see nothing but a blank
> >screen.
>
> Sorry, I don't understand. Are you saying that when you select an entity to
> blink, it just disappears and doesn't redraw?
Yes.
Bill Farmer
You sound like a man much like myself. Got my PHD (Post Hole Diggers or
Piled Higher Deeper) from the College of Hard Knocks.
In R14 with an entity highlighted as soon as you execute another
command, it doesn't have to be redraw, the highlight turns off.
Yep done pretty much the same thing, only we use 2 separate programs.
One to glue, ,join, heal,etc. lines and arcs, no 3d lines yet, and one to
change directions on lines and arcs for CNC stuff so that they all are
running the same direction (Clockwise or Counterclockwise, for those that
are unfamiliar with Numerically Controlled machining processes.)
Boy its a bummer when a tool is going one direction on a cut and then
has to go the opposite direction for the next segment. That controller sits
there and says +ACI-Make Up My Mind+ACEAIg- +ACI-Forward or backward?+ACI-
Bill
Steve Doman wrote in message +ADw-73t8ic+ACQ-jmi9+AEA-adesknews2.autodesk.com+AD4-...
+AD4-Bill,
+AD4-
+AD4-Your +ACQ-0.005 worth is always welcomed. So, are you saying that after the
join
+AD4-operation, the lines are left in a highlighted state? Meaning that the
user
+AD4-needs to do a redraw to clear the highlight?
+AD4-
+AD4-The first glue/join program I used was back with Release 9 ( anybody
remember
+AD4-KAST menu from KETIV? ). The program I am working on today is just an
+AD4-improvement of this old idea. I had downloaded every glue/join program I
could
+AD4-find on the Internet. All of them failed to weed out noncollinear lines
which
+AD4-was my most basic requirement ('cause I do CNC drawings and must). I also
+AD4-needed a glue/join program that works CORRECTLY on 3d lines, a nice touch
when
+AD4-working in paperspace mviews. So, after wasting a lot of time downloading
and
+AD4-testing everything I could find in the whole wide world, I thought I would
just
+AD4-write the darn program myself and then post it somewhere on the Internet
for
+AD4-other to use free. It has been quite the learning experience and I must
admit I
+AD4-was/am over my head. I have yet to add the arc join code+ADs- but that's
planned
+AD4-however.
+AD4-
+AD4-Thanks,
+AD4-Steve Doman
+AD4-
+AD4-
+AD4-Bill Farmer wrote ...
+AD4APg-Here's another thought for you (but no code). When you pick the lines just
+AD4APg-have them highlighted after the join operation if the join operation was
+AD4APg-successful and not if unsuccessful. Just throwing in my +ACQ-0.005 worth. I've
+AD4APg-got a program that I've been using for years to join lines (heal,
complete,
+AD4APg-or whatever term you choose) +ACY- arcs into circles. The command line informs
+AD4APg-you of a successful operation on lines. There is no need for it when
+AD4APg-converting arcs into circles.
+AD4-
+AD4-
Steve Doman
Oh, yeah. I still have my Compaq DeskPro 286 w/12mhz/1mb ram/4omb h.d. and
a copy of Release 2.6 still running on it. Just for kicks, I'll fire it up
and play with it. Remember the Axis command?
'Gone South to the city with flowers in your hair! :)
Steve Doman
Dave Jones wrote...
Steve Doman
Well I'm confused. If I highlight an entity using R14 with the following line
of code:
(redraw (car (entsel "\nPick a line to highlight: ")) 3)
The highlighted entity will stay highlighted until it is regenerated. Maybe
your talking about those new-fangled grips?
As far as CNC goes, we use AutoCAD to do the drawing of the parts and also the
layout of the parts as it sits on the machine. The drawing is then IGES into
Mastercam where we generate the actual NC code. I sometimes flip back and forth
from AutoCAD to Mastercam all day. Mastercam is menu and function key driven,
whereas I have AutoCAD setup with short alias names. I keep screwing up because
I sometimes forget which application I'm running. We have two CNC routers, btw.
Got any hot CNC lisp routines to share? I am looking for a way to chain line
segments. Thought that would be a cool feature to add to the UnBreak routine.
Can you imagine an automatic glue/join routine! Window over a group of lines,
and let it glue/join any and all possible end-to-end collinear line segments it
finds.
Regards,
Steve Doman
http://www.boden.com
-----
Bill Farmer wrote...
...
>In R14 with an entity highlighted as soon as you execute another
>command, it doesn't have to be redraw, the highlight turns off.
...
Dave Jones
<ste...@onlinemac.com> wrote:
>
>Oh, yeah. I still have my Compaq DeskPro 286 w/12mhz/1mb ram/4omb h.d. and
>a copy of Release 2.6 still running on it. Just for kicks, I'll fire it up
>and play with it. Remember the Axis command?
nope, didn't start using Acad until R12 DOS. A mere beginner I be.
And, my first computer was the 386 with 1mb RAM and a 40mb harddrive.
Now them were the days! Couldn't run Acad on it though cause no math
processor, so the 486 came to be.
>
>'Gone South to the city with flowers in your hair! :)
yep, learned the ways of the world. I was actually in Berkeley, where
free concerts, free love, and, weeellll lots of other groovey stuff
was happenin' :)
Dave
Bill Farmer
When you are ready to "unhighlight" use the *entupd*. You could also use
grips/gripped. I was thinking about the *pickfirst* variable originally.
Your code from below would maybe do something like this:
>(redraw (car (entsel "\nPick a line to highlight: ")) 3) change to either a
selection set or list of entities but simply stated
(redraw e1 (setq e1 (car (entsel "\nPick a line to highlight... "))) 3)
*then heal glue or whatever*
*maybe do something else*
(entupd e1)
As far as CNC stuff. Very little. Most of the stuff I did was a few
years back for my brother's machine shop. About all we do here is make sure
that the line work in our flat patterns is all running the same direction.
The CNC programmer and his "little bag of tricks" takes care of the rest.
The most recent little ditty was to take an existing drawing or file
containing X & Y coordinates and drawing the lines and arcs all in the same
direction (ie CW or CCW). These drawings are typically flat patterns of
curved & notched (when finished) blades for air movement equipment.
Sounds to me like you've got a start for "AUTOGLJO". Keep it under your
hat<G>. Somebody might think it's connected to "GI JANE". hot cha cha chaaaa
Bill
Steve Doman wrote in message <73vhdr$ot...@adesknews2.autodesk.com>...