Delaying motion enable after machine-on

andypugh wrote:

The problem I have found with any debugger built in to an IDE in the context of LinuxCNC is that you can't really tell the IDE how to start LinuxCNC and run the program you are editing.

forum.linuxcnc.org/10-advanced-configura...debugging-in-pycharm

This thread makes it sound like it isn't too difficult using pyCharm. But this is really straying from the original issue of this thread. I'll do some experimenting on my own with respect to debugging. After installing 'idle', I've remembered that I've had to use it before and really hate the limited interface so that's a non-starter.

I'll see about geany and whether I can figure out how to install it, along with pyCharm. I hate to get distracted from my original course though. Maybe I'll be able to make some small tweaks and not have to worry about debugging after all.

ozzyrob wrote:

Generall your build cycle will go like this, for a Run In Place (RIP) build. This makes no changes to your existing install as everything is contained within the linuxcnc-dev directory.

ozzyrob wrote:

Everything the rip-environment sets up stays valid in the current terminal window, if you close it the window,the setup (paths and such) are lost. So if you close the terminal you you will have to use the command again to setup the new terminal to run the version you just built. If you don't typing linuxcnc will run the version you install via synaptic or apt-get.

While this is ok for development, I need to have a roadmap to make this completely idiot proof for system restarts. In the field this will all need to start without user interaction. I suspect this is possible through scripting, at least I hope it is.

Are there any other serious pros/cons to a RIP build?

ozzyrob wrote:

As previously stated I did run a test with your config and the changes to code with the new hal pin, I can't really say it does exactly what you want......but I did change one of the messages to how you wanted and setting the motion.inhibit-homing to true does in fact inhibit the homing process. It might be worth looking at the code, even if all you want to do is change the messages to something more meaningful to the user.

I'm leaning heavily toward just doing away with Axis for this. To leave it in place for the final iteration would be foolish anyway. It would confuse the user and leave the machine vulnerable to damage through ignorance and curiosity. As mentioned, it will be a single-purpose machine so having a small set of command buttons and a way to instruct the user is not only sufficient but ideal.

ozzyrob wrote:

I have been working on a way to migrate a Virtualbox disk image (well a partition of to to a real HDD) and what I'm using now is a migrated version, was once a virtual box linuxcnc system partition and is now running on real hardware from a real disk. The beauty is that if you mess it up, it is very easily re-established to how it was.

This sounds intriguing. Maybe you can start up a thread on this if you have something that works. I see it as a way to develop a whole system on whatever computer you want, then transfer it directly to the target computer.

After you finish making the changes you want you can build the deb packages and install them, using dpkg (more on this later), so that you no longer have to worry about the RIP environment.......The RIP environment can be viewed as a way of trying things out without "messing" up the installed version.

sudo apt-get geany
and
sudo apt-get geany-pluigns
or you can combine it all on one line
sudo apt-get install geany geany-plugins

I am not really following this thread but, with delaying motion enable after machine is on, why don't you just enable the drives with a relay and when the machine is turned on run a timer and then energize the drive enable relay? This can be done in classic ladder pretty easy.

Let me think..... With the leading edge trigger of Motion-is-on fire a timer with an output to energize after the timer of 6 seconds or so.
That output will be linked to drive enable relay. Have that output latched and in series with the latch put the trailing edge of motion-is-on contact so when the machine is turned off or e-stop condition, the drives will be disabled.

That way you cant jog or home until after the time period. If you do try to jog it will throw a joint error.

Is this what you were looking for?

You may also turn on a lite following drive enable labeled. "Machine is Really on".

I haven't tried this but theoretically it should work.

bevins wrote:

I am not really following this thread but, with delaying motion enable after machine is on, why don't you just enable the drives with a relay and when the machine is turned on run a timer and then energize the drive enable relay? This can be done in classic ladder pretty easy.

Let me think..... With the leading edge trigger of Motion-is-on fire a timer with an output to energize after the timer of 6 seconds or so.
That output will be linked to drive enable relay. Have that output latched and in series with the latch put the trailing edge of motion-is-on contact so when the machine is turned off or e-stop condition, the drives will be disabled.

That way you cant jog or home until after the time period. If you do try to jog it will throw a joint error.

Is this what you were looking for?

I either misunderstand your reply, or it doesn't work as I need it to. The start-up sequencing is as follows:

1. Machine physical switch on, power to Mesa card & PC power on/boot up
2. Operator gives "control on" signal through physical switch (previously UI). Power is connected to drives through e-stop relay.
(delay 2 seconds)
3. Drives are enabled
(delay 8 seconds)
4. Z-axis brake is released, as all drives are assumed to have control over movement now but aren't yet commutated
5. Wait until all drive "Commutation Complete" signals are true (could be 10-20 seconds)
6. Allow jogging and homing

Thus, I can't delay drive enable because they need to be enabled to commutate. Once the drives are enabled using the standard Axis GUI buttons, there is an assumption that they are ready to be moved - which is not true in this case.

I'm not in favour of allowing a cryptic error message to be shown to a layman operator if the situation can be more gracefully handled ahead of time. The same goes for a sign/message that says "Wait 30 seconds before homing machine". Good luck with that one.

I believe my problem will be resolved by using hardware only buttons and a custom GUI. All of my troubles would go away if I could select a different motor/drive combination but the gods aren't taking pity on me today.

The "cryptic" messages you aren't crazy about come don't come from Axis. Although I dare say Axis has a mechanism that allows then to be displayed. I wouldn't totally inhibit the error messages for obvious reasons. When something does go pear shaped how will the operator relay to his\her supervisor what is or is not happening ?

So if the drives give a signal that they are ready to home why not just make the changes to the code, as previously mentioned and feed those signals to the motion.home-inhibit pin that is created ? Maybe feed the signal from each of the drives to a logic gate so the motion.home-inhibit pin is put in the correct state when all the drives are ready ?

This surely would be an easier and safer way than time delays that will just let everyone\thing assume all is ok after a certain period of time ?
The code changes are very minor and easily implemented.

But if you want to build a gui from scratch and rely on time delays......

ozzyrob wrote:

This surely would be an easier and safer way than time delays that will just let everyone\thing assume all is ok after a certain period of time ?

But if you want to build a gui from scratch and rely on time delays......

I hate fixed delays and I'm not a GUI guy. But have another read over the start up sequencing. I do not get any signal telling me the drive has _started_ to commutate. This is only of particular concern for the Z axis which will FALL if not controlled either be the drive connected to the ballscrew or the brake. When first enabled, there is NO CONTROL. I thus have to keep the brake enabled for ... how long? I don't know. I have no signal telling me that the drive has control over the axis and has started it's commutation routine. I only have an observed maximum time within which the spindle/Z-axis will fall if the brake is released too early. If, however, I leave the brake engaged too long there is too much resistance on the axis and it can't commutate (or makes a hell of a noise doing so and potentially damages the brake). I do have signals that tell me when commutation is complete, and I plan to feed these through an AND gate/component to signal that everything is set up and ready to go. It's the in-between stuff that's the problem.

It's a crappy system to deal with, no doubt. But it's the system that's currently on my plate and I'm attempting to deal with it the best way possible.

I don't intend on masking any error messages. You failed to grasp my point that displaying an error message for a preventable condition is unnecessary and uncreatively lazy. Error messages are for _unhandled_ cases. You know those sections of code prefaced by the comment "we should never get here"? Yes, those ones. And yes, there are other situations where no further action can be taken, so an error must be displayed, but this is entirely preventable. I KNOW that the user will have problems trying to home _any_ axis before the commutation has completed. It's my _responsibility_ to prevent them from doing so.

The fact that the error messages are cryptic and unrelated to the problem is beside the point entirely, but I won't hesitate to draw attention to these whenever I can as this might get someone to put more thought into communication with users of their software.

I do have signals that tell me when commutation is complete, and I plan to feed these through an AND gate/component to signal that everything is set up and ready to go.

Ok fair enough there will need to be a time delay before releasing the brake, my bad for not reading properly.

After the commutation is complete signal this is when you can home ?

If so why not feed this signal to motion-inhibit.home signal ?

The commutation is complete signal can also be used to inhibit running a program and moving the drives via axis......I'm sure I've seen signals such as these in his run-pause-resume setup.
linuxcnc.org/docs/2.7/html/man/man9/motion.9.html

If you actually look at the code regarding the error messages you will find that they are triggered by a something that can't or shouldn't due to certain signals happen. I wouldn't call them lazy.

Eg. trying to run a program prior to homing

The message displayed is: Can't run a program when not homed
Just thinking in a worse case scenario......
It would not be an ideal situation for Linuxcnc to home a machine.......what if it was a accidental press of run when the operator was placing material in the machine ? Or noise (which is an issue unto itself) onto the signal wire ?

ozzyrob wrote:

The commutation is complete signal can also be used to inhibit running a program and moving the drives via axis......I'm sure I've seen signals such as these in his run-pause-resume setup.

Yes and no. The problem is in the way the UI handles the button. I mentioned this in an earlier post.

I have since realized that it's a complete waste of my time to even try to get Axis (or another existing UI) to work with this, as this is NOT a milling machine. It's a custom piece of hardware that uses G code and the excellent motion controlling abilities of LinuxCNC. I got into trouble because I've been using Axis to configure and debug the system. The UI has very little correspondence to the end use and, as I have already mentioned with more detail but less emphasis, would confuse the hell out of a simple operator.

ozzyrob wrote:

If you actually look at the code regarding the error messages you will find that they are triggered by a something that can't or shouldn't due to certain signals happen. I wouldn't call them lazy.

You misunderstand my meaning. It is lazy to let a default error message happen when it is preventable through UI design and/or logic. In this case, *I* would be lazy not to handle this properly like I'm trying to do.

ozzyrob wrote:

Eg. trying to run a program prior to homing

The message displayed is: Can't run a program when not homed
Just thinking in a worse case scenario......
It would not be an ideal situation for Linuxcnc to home a machine.......what if it was a accidental press of run when the operator was placing material in the machine ? Or noise (which is an issue unto itself) onto the signal wire ?

In your first example the correct UI design would be to disable the software "Run" button when the machine is not homed. Hardware buttons can't be disabled and thus it would be appropriate to display a message to the user indicating why their button pushing isn't having the desired effect.

In the second case, this is where door interlocks, interlocked guards, and light curtains come into play. It's a completely different thing and is almost certainly absent on hobby-shop machines. The eventual plan for this machine will be to have a light curtain disabling the machine while the operator is in the "danger" area. I'm not even close to that point yet, with my documented struggles here being part of the cause.

The third situation is a bit far fetched, but is also a case for guarding. Motion should not be possible when a part of the operator's body is in a machine location that can cause injury. All the more reason not to have to deal with the UI, which is not designed with these sorts of things in mind.

However, getting back to my original comment, I was referring to the message "motion stopped by enable input", which is admittedly not as cryptic as some, but also doesn't tell the user what they need to do to fix the problem. On top of everything it can and should be prevented. The buttons to perform actions should simply be disabled when in a state where their use is to be prevented.

(sigh) As much fun as this is, it's keeping me from getting some real work done on this. I do appreciate helpful suggestions, but I see that I've been baited into getting very much off topic.

I'm going to let this thread rest for a while.