• This forum is the machine-generated translation of www.cad3d.it/forum1 - the Italian design community. Several terms are not translated correctly.

autocad behaviour with long lisp interactions

  • Thread starter Thread starter Giuseppe Beatrice
  • Start date Start date

Giuseppe Beatrice

Guest
Hello, everyone.
I would like to expose a problem that I believe interests all those who use lisp commands that involve very long iterations (cycles with while or foreach commands or even vl-some etc...).
when this occurs, a rotating wheel appears on the screen and the message "autocad does not respond"; In fact it is not so, since after the time necessary to run the cycle, everything goes back to work and the program lisp also continues.
I then tried to monitor the cycle with progress bars (please provide on this forum in another discussion) but also these at some point stop and are therefore not of any usefulness.
I ask you: is it possible to do something to avoid such behavior?
it is necessary or appropriate to introduce perhaps some pauses, and how?
Could you propose some examples of programs that can solve this annoying drawback?
Thank you in advance!
 
I usually show a value that indicates the percentage of the work done.... so that more or less the user realizes how much it will take to finish the job.
Obviously this percentage is indicative as it is based on the n. of cycles that you intend to achieve, instead it is possible that something in the program allows to exit first from the loop...
substantially when I imagine that the cycle is quite long, I insert this sub:

;
;
;------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
%
;------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
(percentage dwelling)
; ;
;; index = is a number that is increased before recalling this subrutine
;; num = the total number to be reached (when index = num we are 100%)
;; increase = indicates the step by which the percentages are displayed: es.with a value
; 10 values are displayed 10% - 20% - 30% etc.
; ;
;; the basic formula is 100* index / num but to obtain only the values established by
;; variable increase must be divided the result by increment, remove (fix) the
;; figures after the comma and remultiplicate for the variable increase.
;; example with increase = 10:
;; in this case, the percentages from 0% to 9% - from 11% to 19% etc. ... are not displayed
; but expects to reach a multiple value of 10 (10% 20% 30% ... etc.)
; ;
(setq perc (* (fix (/ (* 100 index) num) increment)); turn into %
(if) (perc perc)
(prompt "\r")(prin1 perc)(prompt " %"); video printing
)
(setq perc1 perc) ; record updates

(if (and (> perc 100) (length tlst) 3)) (setq indior nil)
;
)
;



then in the cycle I enter a command of the type:

;
(setq index (+ index 1)) ; increase index ...
(percentage index number 5) and update the percentage to video.
;

... that I want to update the percentage.
 
I thank you for the xl11start answer, but -as I said at the beginning - I have already predicted a routine monitoring of the advance of the command, which works well until the required operation takes only a few seconds.
the problem I have highlighted is presented with a lisp function that performs the order in a list of a collection of many polylines (not less than a few thousand, extracted from a ssget instruction) according to the coordinate values of the extreme points.
In these cases, which usually take away no less than 20-25 seconds, the monitoring bar typically comes to indicate values around 10-15%, after that everything stops, the message "autocad does not respond" appears and a scrolling wheel (in some cases when the running time exceeds the minute, even the display of the design fades). You also understand that this causes anxiety about the outcome of the operation, but then, suddenly, everything returns normal and the execution of the project lisp resumes regularly.
That's the problem I'd like to fix, but I don't know how to do it.
Anyway, thank you for the availability, and I hope you can help me.
 
That's weird. I never did.

I'm doing long operations too. but the counter goes on anyway. ...

Let's say that the word "autocad doesn't answer" can happen... but only if I go to open other windows and other software while the long operation is taking place... but autonomously, without touching anything never happened to me. . .
 
View attachment albero polilinee.dwgView attachment costruzione albero polilinee.LSPI attach an elaborate dwg containing about 800 polylines connected to each other to a tree.
I also attach a lisp program that asks to select any of the polylines, which will constitute the beginning of the polyline tree.
the program then searches for the polylines that have one of the two extremes that coincide with the one selected and the "connected" with it; the successive polylines are then "connected" with the same search criterion.
If all polylines obey the construction criterion, the program eventually builds a list with the lpt+ent variable, which can then be used, for example, to calculate the lengths from the source point to each terminal branch.
the program starts automatically as soon as you load it, obviously with the open design.
I have inserted both the calculation of the running time and a progress bar (geniously provided to me in other discussion on the forum), visible at the bottom left on the command line.
on my computer (autocad 2014), the program takes little more than 20 seconds, but the problem is precisely that "circle" that appears when the progress is about 38% and the written "autocad does not respond" appears... instead it is not so, since if you have the patience to wait, you will see that the program completes its operations.
ps if you want to control variables, enter a program break point on the last line.
hello and thanks for availability
 
to me by mistake:
select branch origin; error: no function definition: lm:listdifference

(maybe because I have autocad 2010!)
 
try a bit my lisp: it is used to combine all the polylines together (obviously when more than 2 lines have the same origin in "chooses" one).
I did it to merge all the curves of the level... .

Anyway... it takes a few seconds and comes to the end without any problems... .
 

Attachments

as to the program you post, unfortunately does not respond to my purpose, which is completely different and refers to situations like that of the drawing.
Anyway, thank you.
 
I've tried again...... continues to make a mistake... .

Unfortunately I have no chance to try it on higher autocads.. . .
 
I tried, but the circle didn't appear, this is my test:
Code: 
command: vl
vl select branch origin
time running program: 10563 ms
command:
the problem highlighting could be something similar to stack overflow, in current pcs brought mainly by the use of recurring functions, type lm:listdifference.
 
I thank you infinitely gp, even if with the delay of a few days, for your competent and precise answer; Is there any way to avoid the overflow stack highlighted by you?
 

Forum statistics

Threads
44,997
Messages
339,767
Members
4
Latest member
ibt

Members online

No members online now.
Total: 244 (members: 0, guests: 244)
Back
Top