Forward Step / Backward Step - Vexta Question

BrendaEM wrote:

I feel bad because I am not used to needing help from other people this much

CNC systems are complicated. One of the most complicated overall systems that there are.

So, letting Stepconf set up the e-stop pin was not going to be enough....

I am not sure what options you chose. If you selected a parallel port pin to be e-stop then I think it did the right thing.

This creates signal called "net estop-ext " which reads hardware parallel port 13, correct?

net estop-ext       <= parport.0.pin-13-in

Yes, that is correct.

I thought that the Linuxcnc wanted wants a FALSE state to proceed, meaning that a NC Estop switch hadn't been tripped.

You can invert the sense of the P-Port pin (in stepconf or by editing the HAL) to get this behaviour.
setp parport.0.pin-13-invert 1 (Edit) Sorry, input pins use the in-not rather than being explicitly inverted.

Does this create a signal called "estop-out" which pretty much gets its input from the GUI button in axis? (via LinuxCNC's subsystem)

net estop-out <= iocontrol.0.user-enable-out

Yes.

If so, then that line not going to help me. I just want my hardware button to toggle the screen button. I want to shut off the estop event so I can enable the screen Power button, so I can turn my machine on.

That is certainly possible. I have a machine where the on-screen button is entirely under hardware control. (which isn't actually what I intended . I think that involves the pin you mention later, iocontrol.0.user-request-enable.

The next problem I am having is: I don't know if LinuxCNC is going to watch a HAL pin, or if I have figure out how to create an event.

Every HAL pin is polled every mS.
Well, that isn't entirely true, HAL pins are actually shared-memory locations and each HAL module reads its inputs and updates the outputs every time the thread it is in runs (and the modules run in the sequence of the "addf" commands in the HAL file)

Wouldn't this be enough on it's own? As it's connecting the "estop-ext" signal to Estop watcher.

net estop-ext => iocontrol.0.emc-enable-in

Yes. I think that stepconf just creates the estop-out signal in case you want to use it in a different HAL file. As far as I can see it isn't used in your HAL?

To read the documentaiton also looks like this is involved somehow, but no one has brought it into play.

iocontrol.0.user−request−enable

It might be worth fiddling with the pins in a simulator to see what happens.
If you open an axis sim config, then open Machine -> show HAL configuration you can set up a "watch" in the "watch" tab of the various HAL pins, and you can change their values in the command line at the bottom of the other tab.
However I prefer to issue the commands from a terminal window, because then you can have tab-completion.Will link your terminal in to the running HAL session, and then you can link and unlink pins "live" and change their values. For example

I don't understand why I would want to create signal loopback with nothing in between to control it, start it, or stop it. This would seem to lock the system into a state, but I how could I chose which?

It seems to work for simulator systems with no hardware. Presumably it's due to the order of execution.

Sigh. I am not very confident my machine will be running soon : (

I think you are very close.
You could comment-out the current e-stop lines (for the moment) and put in the loop
net estop-loop iocontrol.0.user-enable-out iocontrol.0.emc-enable-in
for testing.

Then you should be able to release e-stop and turn on the machine.

Do your drives have an "enable" input that needs to be set?
Are the motors free or locked?

You actually have:
Which is a bit odd, but ought to work (the second "setp" for each parameter should over-write the first).

Out of interest, how does your base-period (in the INI) compare to the step length you are seeing there?

If I am reading things right that is a 22uS step, which is probably the shortest step that can be made with your base period.

I think the question is why the rise-time is so slow. Do your drives have an option to use sinking inputs? Most parports have rather more drive capacity sinking current than sourcing it.

I have heard good things about the Vexta 5-phase steppers and drives.

Some of those interface boards for the parallel port need a power supply. Some (apparently) need two. I assume that it has those?

If the drives have opto-isolated inputs, and you can get to both sides, then I would suggest a 5V supply pulled-down through the opto by the parport driving the drive directly. (bypass the interface board).

It seems like the problem here might be the parallel port or the interface board. (I think that we have concluded that LinuxCNC is making steps? The step length can only be integer multiples of the base period. (Actually, there is a way to get shorter steps, but it doesn't gain you much really).