How do I start my 7i77 without Vfield on at start?

I'm trying to retrofit my 1990 model Maho MH600E.

It has a Philips 432 controller on it, and I'm trying to replace that with LinuxCNC using Mesa 7i77 and 7i84 (and 5i25).

The idea is to reuse as much as possible of the original machine, including servo drives and most of the built in electronics and relays. The idea is to make the computer interface the machine like the original controller (replace it function for function). This includes fitting the computer with the same connectors and making it communicate with the machine as the old controller did. A major part of the idea is to be able to switch back and forth as a way to verify the retrofit. It makes it that much easier to have something that works to look at rather than have to reinvent most of it.

The idea is to not have to rebuild everything in there with the work involved in that. After all most of the functionality built in to the machine is quite well thought through. It's just that the controller itself with it's ancient interface and severe limitations needs to be replaced.

Most parts of this is also fairly straight forward with no problems to implement it. Encoders, servo outputs and such is no problem.

The major problem now is the way the IO is working on the Mesa cards. The cards can work with 24V quite fine, no problems there. And they can drive the relays as needed.

And up until now I figured since they have separate inputs for logic power to the IO I thought it would work to do what Maho do. They have a built in safety that turns on and off the 24V power to the actual IO drivers so it's only on when the controller is out of e-stop. It's divided by the galvanic insulation. The controller side don't know or care whether the OI interface part outside the galvanic insulators are powered or not. But if they are they will at all times be sett in a state controlled by the logic on the computer side.
The idea is to prevent anything from happening by accidentally turning on or off something by accident before the controller is starting up (or in another way isn't doing what it's supposed to do). And to prevent things from happening while e-stop is engaged. German safety at work here then.....

So..... it is possible to separate power to the IO logic from the IO drive power to copy this behaviour?

I have come to the sad conclusion that that isn't possible with Mesa cards...... which to me is a hard blow....

After all what is the point of providing for sepparate power for the two parts if it's not possible to turn the power on and off on the IO while the system is running? I mean, is there a point to be able to separate them at all then? I understand that the controller needs to communicate with the IO logic processor. But I was under the impression that powering up this should be enough for the software and it would be possible to turn the power on and off to the output part as needed by the system? In my case that is the basic philosophy behind the whole control system in my existing setup. And to be honest I have to admit it's not a bad idea. So I'd like to keep it like that for the future as well.

But it turns out this doesn't work at all..... if the power to the IO driver section is shut off the whole controller needs to be restarted..... And it has to be restarted with power to the driver section on. Which in my case isn't possible. At least not without rebuilding the whole system and removing this safety system.

The reason is very simple, to get my machine out of e-stop I have to press buttons in a sequence (not such a good idea from the Germans there I agree....). And only when doing this the IO section is powered. And during that power up sequence output 2 needs to be enabled for the e-stop chain to "catch" and stay on. That means the logic part of the OI needs to route the internal e-stop signal to output 2 (no problem there, I have made that work already). Then as the IO section is powered all the sett outputs are turned on.

Is there a way to reprogram these controllers to do anything like this? I don't really understand why there is even made provisions for powering them by separate supplies if functionality like this isn't implemented?

The only alternative as I see it now is to bypass the safety system and reroute 24V straight to the IO permanently. This will bypass the whole safety system built in to the machine, and I'd really like not to do it this way. That would mean redesigning the whole system, which is a major undertaking I'm not keen on doing since I don't think I will get it as good as it is now.

At first I thought it would be ok as long as I started up the system with 24V on the IO. But it turns out that powering the Vfield off while the controller is on, leaving the logic power to the OI on isn't enough to keep the controller happy. When I reapply power to Vfield again the outputs for e-stop doesn't come back on. And the only way to make them come back on is to restart LinuxCNC......

I'm really wondering if I'm the first one to try to use these cards like that? Is the Philips controller my machine came with the only controller to do it this way?

I don't know much about it but isn't this exactly how Opto22 IO systems work as well? A separate rack with actual relays on the end to protect the controller. And the possibility to turn the power to these relays on and off as the same kind of safety I speak of here.

I can understand the output drivers needs to read inputs and set outputs when powered on, unlike relays and opto insulators that don't care what happens on the other side. But it shouldn't be that hard to program the logic to do a IO read/write sequence each time Vfield is turned on? After all the controller itself have power all the time, and should be able to read Vfield continuously and know when to engage a new read/write sequence and reset the communication to the host telling it that it's back online when Vfield is turned on?

Am I the only one who think like this (except Maho 25 years back)?

I'm just asking because this is a problem I didn't even consider I would be having.....

What are my options here?

Anders

Actually it seems pretty crazy to remove _control_ power in Estop

Why be blind to all inputs and lose control of all outputs in a Estop situation?

Servo power/ spindle power / toolchanger power etc absolutely!
even coolant maybe but control power? that's just wrong

it _may_ be possible to work around this by only starting the sserial port
after you are out of Estop but this would require you defer loading the hal
code that deals with remote pins at startup

So you are telling me this is the only vintage controller who is doing it this way? I have no experience with other brand machines as my machine is the only one I've been working on.

But there are some very clear reasons to do this on my mill. Some of the logic of how things behave is done purely as hardwired relay logic. Switches and sensors are powered all the time, so several of the inputs are on immediately after the machine has power applied. Which also turned out to be the reason I fried my last Mesa cards (in combination with some bad mixing of ports).....

As power comes on there is no 100% way to be sure of (at least so thought the manufacturers of this controller) that all the outputs have logic set so that only the outputs that can be turned on are in fact turned on. And I guess their thinking was that if none of the outputs are on we should be safer than applying power to the outputs and potentially let random states in the logic screw things up.

And everything is wired so that if all outputs are set low everything stops and should be safe.

The thing is that all these safety precautions are woven so deeply in to this machine it's almost impossible to get around them. The only solution will have to remove everything and start from scratch. Like the doors. It's only possible to start the machine by opening AND closing the doors. It's not enough for the doors to be closed when you want to start it. The machine insists on you opening and closing them in order for it to know that it actually knows the door switches are working as expected. Sort of a prevention system to keep users from bypassing bad door switches and such. I have found out how to bypass this rather annoying "feature", but this is only an example on how thorough they have been at implementing safety in every part of this machine.

So working on this machine you need to adapt their way of thinking, or you won't be able to get anything done. It is a little like working with a machine with sinking outputs (like the Maho is now), with only sourcing outputs available on your new system (like the Mesa don't allow for turning off the output). There are reasons for both approaches, and both have their merits. The safety philosophy behind this machine is truly built around the fact that when anything dangerous happens it's safe to disable all outputs, and everything should stop in a safe way.
Not being able to read the inputs when in e-stop is probably a not so good thing though. But it seems these Germans think of e-stop as a state where the machine needs to be shut off from all ways of doing anything with the machine that can move.
And to be honest, I would prefer to be able to read inputs regardless of whether the machine is in e-stop or not.

But I don't feel like redesigning the system to work in a different way..... I might as well rebuild the whole electrical system of the machine.

It actually took me a long time to figure out this is how it worked. Initially I wasn't able take my machine out of e-stop. Apparently there is a rudimental (1 bit) parity check on the outputs (as a safety). After a lot of digging I found out this parity checking circuits are in fact powered by the output power, meaning it doesn't power up until after the machine is out of e-stop. A bit of a catch 22 thing there then. Machine won't come out of e-stop because there is parity error. But the parity error checking circuits are powered only when the machine is out of e-stop. To bypass this, the power up sequence use a switch to temporary power up this circuit in order to turn the machine on (or rather take it out of e-stop). It turned out the only way to get around this was to switch

Now one thing I COULD do is to wire up 24V permanently to the Mesa cards to keep them happy. Then apply the logic to all the outputs so that none of them can be turned on unless the machine is out of e-stop.

This would be almost the same as how it is on my mill already.... Only now I have to trust the controller to shut off outputs instead on relying on a 100% sure way to make the machine safe as it has now. I guess the Mesa hardware is made to be used like this, and should not have any problem with being used like this.

I'm not that steady in HAL logic, but one method I can think of is to apply an AND logic to all outputs and AND each of them with +24V in (the one meant to turn on the IO). This way they should behave like my present controller. The only "problem" is that I need to set up a large number of AND functions.... and my config files will look rather messy.
Is there a simpler way to do this? An "all digital output enable" kind of function that could simplify this? Or maybe I should make a separate logic file to handle this separately? Then I will be able to make my config files look more normal. Although I can't route any output signals to the pins directly, only to the AND functions. But I guess it will be better to do it this way to make it easier to read and apply changes.

Another possible solution is to provide Vin with power at startup of LinuxCNC to keep the Mesa hardware happy and discover all ports. Then it could be possible to run a software loop that monitors Vfield? This data is available in some modes I have read in the manuals. This loop would know when Vfield is turned off or on. On any of these transitions it could be possible to restart the communication to make the system work? As I understand it there is supposed to be a fault when Vfield is removed that should halt communication to the outputs. Or this might be the idea at least?
I have discovered that if I start LinuxCNC with all power on it will start up fine (as expected). Then if I turn off Vfield only (not power to the OI logic part) the red LED's on the cards will light up showing there is an error. But no error is shown on the screen in LinuxCNC....

And if I reapply power to Vfield the outputs are not turned back on, even though everything inside LinuxCNC seems to indicate the appropriate outputs are turned on. The red LED's on the cards disappear, indicating no error is present anymore. Halmeter seems to indicate the outputs are still on, while the LED's I have hooked up to all outputs stay off. The LED on the outputs I turn on before turning Vfield off and on do turn on initially. But after turning off and on Vfield they don't light up again even though LinuxCNC seems to believe they are still on. Is this a bug?
It seems I must be the only one to have attempted to use the IO like this, so it might not have been tested before? But it is in fact a bad thing if LinuxCNC seems to think it is in control, but isn't if a disruption on the power to Vfield happens! A blown fuse that is reset or something means the only way to regain control of the machine is a software restart as it looks now. Or to set the Vin for the output logic to be powered from the Vfield to make sure the cards notice when Vfield have disruptions. I know this is the default setting for the jumpers. And if I chose to use AND logic to accomplish what I need I will most likely put the jumper back to default setting to make sure LinuxCNC knows if Vfield disappears. It seems to me as a safety issue not to do it that way.

This approach seems to be more unsafe as it relies in restarting communication with the IO modules. So the more I think of it the more I tend to lean against the first approach with AND logic on all outputs.

Unless anyone have a better idea on how to accomplish this?

With the AND logic on the outputs I will in fact also be able to read all inputs at all times, which is a plus.

Now I need to figure out how to implement this output logic and make it run in a separate file..... which is probably straight forward for a programmer. Up till now I have more or less relied on PncConf to make my config files for me.... but now it looks like it's time to start swimming at the deep end of the pool. Now it if only weren’t so scary over there with all kinds of unknown Linux issues making things more complicated...

Is there a guide on how to do something like this somewhere I can read? I will have to build a rather complicated logic for my ATC as well soon now, so it might not be such a bad idea to look in to it now.

Anders

1. Estop _must_ remove _primary_ power for all servos/spindle/toolchanger motors/anything
else that could cause damage to people or the machine. ability to enter the Estop state
_cannot_ depend on the state of any control electronics.
2. if you want to disable all outputs, you can set the run state of the sserial interface to false
3. I think its much better to leave the I/O running when the machine is on, why would you want to lose
all control of I/O when in Estop? (linuxcnc certainly has I/O running when in Estop)

1. Agreed, on the Maho this is done by removing power to the IO, thus making sure there are absolutely no way to power ANYTHING moving. To top that up it has another level of "ON", which is needed to power up all moving parts, servos, spindle, ATC. My idea is to replicate this. And this is why I wanted to power off the OI output stages like Maho do.
All I need to do now is to make the Mesa interface behave the same way. As mentioned this machine have so many layers of safety there is no way any moving parts will move unless all safety systems are engaged and are turned on. Which is how I'd like to keep it. So by making sure there are no outputs enabled when out of e-stop I will be sure there are no power going to any drives (except for logic power, which is correct). The question is how this is accomplished.

2. That might be what I'm looking for yes. But I haven't seen any other machines using LinuxCNC do it this way? Is there a manual on how to accomplish this? I believe it's doable if you say it is, you know this hardware better than anyone and I trust you when you say it can be done. But I haven't seen any mentioning of this being used this way before. And it would prevent me from reading the inputs as well, so in that regard I guess it's not such a good idea.

3. I agree it's a good thing to read the inputs at all time. Which is why I suggested using logics to accomplish shutting off all drives and movements by disabling all outputs. Many of the outputs are wired directly to hydraulic switches which will move the ATC. So it's important that the output section is in full control of all outputs and are 100% controlled at the moment the actual outputs are powered. This was done by having a hardwired "enable" mechanism on the Maho.

So, on my machine I first have to take the machine out of e-stop.
Or is it in to e-stop, I always have that confused, to me as a non native English speaker it doesn't sound correct to put something in to e-stop when you actually turn on something that sounds like it is to disable things, not to enable. The word e-stop to me means a circuit that REMOVES power to things, not the opposite around..... anyway....

On my machine this isn't enough to power up the power to the drives. I guess that is how it's normal on most machines. What I have to do to make it move is to turn it on. Or rather, do the door open and close dance. That is the only way to turn the machine fully on BTW. I have a "setup" mode with holding in buttons while working with reduced speeds and such if I want to. But to turn the machine truly on I have to close the doors. Not sure if this is how other machines are doing it. But I guess that's almost the same as turning the machine ON in LinuxCNC.

So I'm assuming it's considered safe to let the output stage on the Mesa cards to be powered, and trust the system not to turn on things unintentionally while not out of e-stop and with the machine turned on?
My Maho is built in a way where they didn't trust in this, so they made a 100% sure way of preventing it from enabling any power devices unless the e-stop chain was powered.

From how I understand other systems are set up I can only assume that this extra safety is no longer considered as needed, which is fine by me.

On my machine it's even hardwired steps to prevent the machine from going out of (or is it in to?) e-stop without the operators influence. If e-stop out of the controller is on the "ON" button have to be pressed twice (with clearing of faults while it's being held down) for it to engage. Only after this sequence of steps it's possible to proceed to turn the machine on by opening and closing the doors.

And any of the e-stop sensors can disengage the e-stop circuit like it's on all other machines. So I have no doubt the machine will be disabled as needed, when it’s needed. All of this is hardwired, so there is no need for the controller to do any measures to disable anything in order to render the machine safe in case of an accident.

This is why I feel confident it's no problem to do what I mentioned with building up logic functions to enable the outputs. The machine WILL shut down like it's supposed to do if ANY of the e-stop sensors disengages. That includes the e-stop signal from the controller, so I will be able to render the machine safe by pressing the e-stop button on the screen on LinuxCNC to make it stop as well without anything except the e-stop output to go low. To be safe I don't plan on using any logic functions on the e-stop outputs. I don't want to risk errors in the logic to cause an accident!
The bad thing about the present controller is that I need to home all axes if I press any of the e-stop buttons. But I assume LinuxCNC will keep on reading the encoders to keep track on how the axes move even if there is no power to the servo drives?

So, do you think this is a feasible way to do this? Using logic functions to control the outputs I mean? As long as the Mesa hardwire behaves and don't set any of the outputs high at any point other than if LinuxCNC is running and in control it should be fine.
When I come to think of it I won't need to apply the AND logic functions to all of the outputs as not all of them are that critical. But the outputs that go directly to the hydraulic functions should have some sort of enable to them?

Anders

What I would do is this:

For safety critical things like hydraulic valves,
I would run them from relay or other power switch (isnt this there already?)
driven by the 7I77 outputs. The relay takes it contact power from the switched 24V
and the 7I77 is powered on when the machine is powered on

The problem with this approach is that ALL relays, also the ones controlling the hydraulic functions are hardwired directly from the outputs of the controller to the relays.
Safety is done by only giving power ON to the output section making them able to turn on the relays section of the IO card only when e-stop is on, thus rendering the outputs unable to power the hydraulic relays until e-stop is on.

Now as the 7i77 isn't able to have its output section turned on and off as wanted while the controller is running there is no way to make this part of the safety chain work..... which is why I've had to do this out of the ordinary attempts at turning the output section of the 7i77 on and off by the e-stop circuit in the first place.

This turning on and off of the output (and input section for good measures) is Maho's first and ultimate way of making the machine safe when not in e-stop.
The second line of defense as you can call it is the way the power going through the relays and out to the actual power device or contactor is implemented The power going through all the different relays are controlled by the e-stop chain. So no hydraulic valves are turned on unless the e-stop relay is turned on. So there will not be power to the actual hydraulic valves unless the e-stop relay is also powered. But I imagine this being meant as a secondary safety from Maho's side.

The system is built with 4 hydraulic functions, each one having 2 directions. 2 or 3 of these are permanently turned on while the machine is on to make sure the ATC is in correct position to prevent leaking oil to cause gliding and such making things go out of position.

Then again the e-stop chain isn't energized unless the controller is actively turning it on and then the operator pressing knobs in sequence. So as it is there will have to be both mechanical and human actions for the e-stop to be turned on to enable the hydraulic functions.

The question is whether this can be considered as good enough? Could this way of doing it be employed by a DIY'er on his machine, and would it be considered safe enough?
I would believe so, but this is a German machine made with all that much more safety built in from the ground. It's probably considered too much of a hassle to be operated because of all of these extra safety measures, so the plan was to loosen a bit on the most ridiculous safety measures implemented on it. The door being the only way to power up the drives being one of them. I will make a switch to override this, but I'm not sure how this is normally done on other machines. I will try to get input from other machines as to how this is best implemented.

Thanks for bearing with me on this..... It's not exactly easy to follow, I understand.

Anders

Well It can be done by by stopping and restarting the sserial port but this
means losing all I/O capability when in E-stop as I said before

theirs a lot more safety built in linuxcnc than a machine controller , having said that , i use a seperate 24v fieldpower unswitched from machine for use with switch on circuits
so once the machine is powered their is a limited 24v supply to only functions that need it at that time.
Switching on axis by F2 powers the rest of the machine , i use a interlocking method that if estop is used then the machine requires a restart , and cannot be started from just F2
But a system error say servo , will not put the machine into the estop loop , only a disabled state .

All estop circuits are hard wired and monitored by linuxcnc ,
also the pc is seperately powered so if estop then you dont loose the pc monitoring, at the control panel is also a key switch that will disable movement for servicing
and also if a door is opened this is in the enable loop , i have a screen tick box that can overide this door for setup

usually if the machine is fitted with a 'dry run ' then that turns some safety such as a door off , to enable you to see the machine in action

if you need any help to implement just shout