Messages

1751

Mach Screens / Re: buttons go blank when pressed

« on: October 16, 2009, 04:32:59 AM »

Turns out its down to my anti spyware. Allowing mach through solves the problem - I'm assuming mach isn't up to any mischief 

1752

Mach Screens / Re: buttons go blank when pressed

« on: October 15, 2009, 04:16:57 AM »

Hi Brett - good to hear from you and thanks - getting there.

Checked dirs - all as it should be. Thing is - on the steelblue set for example - all the buttons have no bitmaps, they're intended to be just transparant "hit sites" if you like - with the button graphic just being part of the background. It seems what's happening is that when you hit a button - it goes black - whereas before it used to stay transparant. I've included some pics. The first is from Machscreen. The second in Mach before hitting the button. The third from Mach after you hit the button. As I say - this example is steelblue but its the same for every set I've tried except 1024.

Ian

1753

Mach Screens / buttons go blank when pressed

« on: October 14, 2009, 09:57:30 AM »

Hi - been a while since I played with any of the alternative screens - steelblue, benny's etc. All worked pretty well previously but now they all have the same problem. When I hit a button it goes blank - i.e. just a black rectangle where the button was. A screen minimise and restore recovers the graphic. Any ideas? (only the original 1024 set works fine)

Thanks

Ian

1754

General Mach Discussion / Re: Must X and Y Have Same Acceleration

« on: October 14, 2009, 06:02:51 AM »

your suspicion that CV will be asymetric is correct. However they have to be quite markedly different before I think you'd notice (depending on your accuracy requirements of course). Personally I prefer to have X and Y accel the same for this reason.

1755

VB and the development of wizards / Re: Controlling a stepper motor from VB

« on: October 14, 2009, 05:37:36 AM »

Hi Andy

What you've achieved with inpout32.dll is about as good as it gets with VB (or any other language for that matter) with windoze after 95/98. It's not primarilly that VB doesn't have the speed, its that any ".exe" runs under the control of windoze and can not get privilaged control of the hardware. Your VB program will send out your pulses "OK" i.e. up to a reasonable speed, but the timing of when they actually get to the parallel port is down to the OS. Windoze (like any other non-real-time OS) is constantly wandering off doing "more important" things just when you needed a pulse.

Of course - what you want to do can be done. After all Mach3 does it. Start by reading about writing a windoze kernel driver. (good luck!)

Ian

1756

General Mach Discussion / Re: G4 versus Sleep

« on: October 08, 2009, 03:22:16 PM »

does anyone ever feel they're living in a parallel universe and that maybe they don't actually exist? - I know I do 

1757

General Mach Discussion / Re: motor madness

« on: October 07, 2009, 11:02:15 AM »

Did but a slightly slower read than RICH and I'm afraid not much of any of the specs actually makes sense or adds up so I think maybe there's a bit of a translation problem going on here. That said - generally speaking (I said generally speaking. So nobody out there kill me ok!) - out of the three possible ways of wiring an 8 wire motor for bi-polar drivers, serial winding is going to give you the hands down worst performance. If you can get better (English) specs that would be good. If your drivers and supply can handle it you'd be way better off with single coil and even better if you could go parallel.

The only other thing I can suggest is that sometimes (its happened to me) the wire colours are mixed up on the motor data sheets. Although the colour scheme you describe is common - I have seen them mixed up before now. Hammer drill is a good description of what motors sound like when this happens. A simple check with a multi meter will confirm they're correct.

Ian

EDIT: actually thinking a bit more, doh, a multi meter won't give you the full story - sorry. The attached piccy shows what I mean about mixed up wire colours. Here's two motors I use and you can see why one threw me. The labels A, A dash etc refer to the same colours BUT the START of the coils are on different colours. Get these wrong and your phases will freak out! The scheme you describe is on the right - you could try the left and see what happens.

1758

General Mach Discussion / Re: Plasma Application, Mach3 torch height control.

« on: October 06, 2009, 01:57:52 PM »

BTW, what do you mean with "pp driver" ?

JP

Parallel Port Driver. I have a Mach on my office PC with no machine attached for just testing stuff and therefore I didn't install the PP driver and a Mach in my workshop driving a machine and therefore I did install the PP driver.

Cheers

Ian

1759

General Mach Discussion / Re: G4 versus Sleep

« on: October 06, 2009, 11:15:03 AM »

As Hood says, yes.

A while isMoving will wait until Mach signals VB it can continue, wheras a sleep is VB guessing how long it should wait. A while isMoving with a sleep is a wait until Mach signals with a well mannered nod to the OS that it can ignore the VB thread for a while and save those precious CPU cycles. However of course Mach might signal whilst VB is asleep which wastes precious micro-seconds - its all horses for courses.

Bottom line is... In any asynchronous multi-thread programming setup, there are usually times when you need to synchronise. i.e. wait for the server to be at a known point before continuing with the client.

Waiting on semaphores (the fancy/geek term for all this malarky) is an integral part of multithread comms so at the moment I can't figure out how this can be done away with but Brian clearly has some devious scheme up his sleeve 

Again hope this helps

Ian

1760

General Mach Discussion / Re: Probing questions, Help!

« on: October 06, 2009, 10:43:57 AM »

Hi Fastest1 - just thought I'd chime in to try to help you not crunch your probe - I know it hurts!. To get familiar with it I'd suggest you probe sideways (in x or y) rather than downwards (in z) using a small block of wood as the trip object. Heavy enough that it will not move for a good trip but light enough that it will be pushed out of the way by a bad (or none) trip. Set your Z so the probe just hits the top of the side of your block.

Don't worry about the wizards at the moment. Until you get happy with it all, you only need to program a G31 X10 or whatever in the MDI and then pick up the actual trip points using the gcode var monitor (2000 for X and 2001 for Y)

Cheers

Ian