Hello Guest it is April 23, 2024, 05:33:07 PM

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - stirling

1881
use a different pin? pin 1 is usually reserved for the strobe line.

This kind of where I'm going - however pin 1 is only strobe for "conventional" printer drivers. Mach's driver as far as I'm aware has no use for pin1 as strobe and shouldn't be doing this - there is no documentation that says "stay clear of pin 1" as far as I know.

Lightbulb above head mad grasping at straws idea! ;D - Bruno (if you're still here) - you don't by any chance have a conventional printer driver enabled as well as the Mach driver on your system that could be taking strobe high through the side door?

1882
General Mach Discussion / Re: 360 deg A Axis homing using an encoder
« on: March 06, 2008, 04:24:26 AM »
Hi Jason - I havn't done this but I have some thoughts that may help a tad.

As I understand it Mach doesn't provide the mechanism for closing the loop of positional encoders per se. For example when using servos, the loop has to be closed by the drive hardware. But I don't think this is the issue for you anyway.

I don't know off the top of my head if Gecko are or not but I don't think a closed loop drive will help you with your objective anyway. In order to implement a home function Mach needs to know about it.

Your problem is that an encoder pulses when the motor moves - it has no notion of position by itself. What you need to know is when it's at a particular position which you can call home. Remember that servo driven axis allways have encoders but they still use home switches. (turn the machine off and on again and then try to find home with a positional encoder)

I can't see any way round it - to implement a home function you need a home switch - not a rotary encoder. Happy to be corrected though.

1883
I started out thinking all this was something to do with Mach3 and my computer, but I'm thinking it something to do with my controller and the mill.
I'd be surprised if it has anything to do with your mill seeing as how it does it when the motors are sitting on your bench - course I may be wrong  :).

Seriously, I'd try to establish if they all do it and if they do, do they do it in perfect sync or not.

1884
Nope, It stay on until I manually turn it off.
I will try to switch the pin and let you know.
Thanks for the help,
Bruno
... and the result was?

Bruno, you can implement all the fancy do-dads you want but that doesn't change the fact that pin 1 is going high and staying high - and it shouldn't be  ::)

1885
VB and the development of wizards / Re: Reentrant code
« on: March 05, 2008, 01:50:06 PM »
Another update: here's a copy of the email text I just received from Cypress:

"I spoke to an engineer about this.  Cypress Enable does not fully support recursion, that is one of the limitations of Enable and will not likely change in any new releases.  You will need to code around this limitation."

So I guess that's it - shame - especially as to implement the local vars correctly is actually pretty trivial - especially when they've already done the "by value" parameter mechanism. Hmmmmm - thinks.... wonder if they implemented "by reference"....

1886
VB and the development of wizards / Re: Reentrant code
« on: March 05, 2008, 02:48:25 AM »
Chris: Cypress got back to me and asked if I could send an example of what I/we thought was wrong. I did this but then they contacted me again and said they couldn't book any support time to look at it as I wasn't the licenced developer. ???

One for Brian when he has time I guess. Anyone know how to escalate this onto his list?

Cheers

Ian

1887
They'll all sync if I hit the cursor keys the right way.

Sorry - I'm not clear on this: If you run all three (or at least two) motors (on the bench) at the SAME RATE and at the SAME TIME - something like g1 x10000 y10000, are the interference patterns perfectly in synch or not?

1888
VB and the development of wizards / Re: Reentrant code
« on: March 04, 2008, 04:36:53 AM »
Hi Ron
I obviously don't know the full issues you've discussed with Brian about Cypress's Enable VB, but this particular issue at least is surely nothing to do with the way it has been linked into Mach. This is an error in the way the the interpreter's code generator builds its stack frames.
I contacted Cypress and had them send me an evaluation copy of their latest version of Enable and even running standalone it makes exactly the same error. I've asked Cypress for their comments and await their reply.
Cheers
Ian

1889
General Mach Discussion / Re: usb to parallel
« on: March 04, 2008, 03:53:15 AM »
yes Stirling has the nub of it - you can use a serial connection if it can send the information fast enough - and in this case we are talking about 16 times or more faster that the parallel port.
Sorry Jim  :) - but if you read my post again I'm sure you'll see that this was not what I was saying at all - quite the opposite in fact.
I'd also make the point that when it comes to discussing the relative speeds of parallel v serial transmission we need to establish some units - otherwise we're not comparing like with like. In fact if we use the same units for parallel and serial we'll find that - surprise surprise - to get the same throughput, by definition they both have to work at the same speed. (actually this isn't 100% true - one issue is that the serial has to work slightly faster to take into account the time needed by the operation of the shift registers in the external hardware to re-parallelize the data).
Art did NOT choose the parallel port because it was faster than any serial port or any other port for that matter - he chose it because Mach did not then need any external clocking hardware to re-parallelize the data and could therefore be sold as a 100% software motion controller - something others were struggling to do or had already given up on.
Cheers
Ian

1890
Hi Bruno

When your spindle switches itself on - does it stay on? or does it just 'blip' on then off again momentarilly?

have you experimented to see what happens if you use an alternative output pin?