Autolisp "command move" doesn't move the exact same distance every time.

Autolisp "command move" doesn't move the exact same distance every time.

Anonymous
Not applicable
1,426 Views
3 Replies
Message 1 of 4

Autolisp "command move" doesn't move the exact same distance every time.

Anonymous
Not applicable

Hello all, I've been dealing with this frustrating issue for a while now, and cannot for the life of me figure it out. At my company, we have two simple scripts that move a selected entity up or down 3600 inches. Here's the code for "Move Down" and "Move Up" respectively:

 

(defun c:md (/ ss)
  (setq ss nil)       ;Set ss to nil
  (setq ss (ssget))   ;Grab the user selection 

  (command "move" ss "" "" "0,-3600.0"  )       ;Move the selection by 3600

  (sssetfirst nil ss)      ;Retain the user selection. (Enables successive "mu" or "md")
 (princ)
);defun

(defun c:mu (/ ss) (setq ss nil) (setq ss (ssget)) (command "move" ss "" "" "0,3600.0" ) (sssetfirst nil ss) (princ) );defun

Seems pretty simple, right? The problem is, sometimes, this command will move the entity not quite 3600 inches. Say, sometimes 3595.5347 inches. Sometimes it will move the object 4.4653 inches.  Sometimes more or less, those numbers change between drawings (and sometimes in the same drawing).

 

As well, it seems to be dependent on the user's zoom level. It doesn't seem to happen at all when the user is zoomed in on the entity. It only happens when the user is zoomed out on the drawing. It doesn't happen if you manually move the entity 3600 inches either, so it must be a Lisp thing. 

 

I've attached a drawing where I'm seeing this behavior.  The horizontal lines are all offset exactly 3600" from each other.  If I have my zoom level so the boxes fills most of my screen, the commands move the boxes exactly 3600". If I zoom out so I can see all the horizontal lines, the command will move the boxes not quite 3600" and there'll be a slight error between the position of the boxes and the horizontal lines.

 

I've also noticed the same issue using the "copy" command in this way. 

 

Any insight into this would be greatly appreciated.  Is there something wrong with my code, or maybe some autocad setting somewhere? I feel like it's probably something blatantly obvious, but nothing I've tried has worked.  

 

Maybe the vla-move command wouldn't have this error?

0 Likes
Accepted solutions (2)
1,427 Views
3 Replies
Replies (3)
Message 2 of 4

Ajilal.Vijayan
Advisor
Advisor
Accepted solution

looks like the osnap affect the move command.

try to turn off osnap before move command

(defun c:md (/ ss osval)
  (setq ss nil)       ;Set ss to nil
  (setq ss (ssget))   ;Grab the user selection
  (setq osval (getvar "OSMODE"));get the current osnap value
  (setvar "OSMODE" 0);turn off osnap
  (command "move" ss "" "" "0,-3600.0"  )       ;Move the selection by 3600
  (setvar "OSMODE" osval);reset old osnap value
  (sssetfirst nil ss)      ;Retain the user selection. (Enables successive "mu" or "md")
 (princ)
);defun


(defun c:mu (/ ss osval)
  (setq ss nil)
  (setq ss (ssget))
(setq osval (getvar "OSMODE"));get the current osnap value
 (setvar "OSMODE" 0);turn off osnap
  (command "move" ss "" "" "0,3600.0"  )
 (setvar "OSMODE" osval);reset old osnap value
  (sssetfirst nil ss)
  (princ) 
);defun
0 Likes
Message 3 of 4

Kent1Cooper
Consultant
Consultant
Accepted solution

I have running Object Snap modes on, and it doesn't do that for me [when done manually], because I have this setting:

EntryPriority.JPG

I suspect you have it set for "Running object snap."  Experiment with the other options.

 

If that doesn't do it, you should be able to avoid needing to save and restore the OSMODE setting, by just putting an explicit NONE Object Snap call before the point designation:

  (command "move" ss "" "" "_none" "0,-3600.0")

[you can omit the e at the end -- the 3-letter abbreviation is enough].

Kent Cooper, AIA
0 Likes
Message 4 of 4

Anonymous
Not applicable

Thanks, fellas, both those solutions worked great. 

0 Likes