Re: [Emc-users] Problem with E Stop Logic
Yes you had previously mentioned the need to use the first board E Stop input and not use the second board’s E Stop input. That was already correctly wired. Matthew Herd herd.m...@gmail.com 610-608-8930 > On Feb 16, 2021, at 7:14 PM, Jon Elson wrote: > > On 02/16/2021 03:58 PM, Matthew Herd wrote: >> So I've got egg on my face on this one. It seems that changing to dout.07 >> in my config solved the issue. No idea why it didn't work for me before. >> I'm certain I tried that in my config, but I can't say. Also, I tried the >> sim config again and it worked this time. No idea why, but I'll take it! >> Thank you again Jon for your assistance! >> > Well, the E-stop loop needs to be wired to the master board, also. Not sure > if you had it > that way before. So, I'm glad it is now working! > > Jon > > > ___ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Problem with E Stop Logic
On 02/16/2021 03:58 PM, Matthew Herd wrote: So I've got egg on my face on this one. It seems that changing to dout.07 in my config solved the issue. No idea why it didn't work for me before. I'm certain I tried that in my config, but I can't say. Also, I tried the sim config again and it worked this time. No idea why, but I'll take it! Thank you again Jon for your assistance! Well, the E-stop loop needs to be wired to the master board, also. Not sure if you had it that way before. So, I'm glad it is now working! Jon ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Problem with E Stop Logic
So I've got egg on my face on this one. It seems that changing to dout.07 in my config solved the issue. No idea why it didn't work for me before. I'm certain I tried that in my config, but I can't say. Also, I tried the sim config again and it worked this time. No idea why, but I'll take it! Thank you again Jon for your assistance! On Mon, Feb 15, 2021 at 12:15 PM Jon Elson wrote: > On 02/15/2021 10:56 AM, Jon Elson wrote: > > The very old boards only gave a few hundred ns for the > > resistor to pull the E-stop/ line up. If there was too > > much capacitive load on the cable, it would not rise > > enough and then the board would go back to E-stop. > > I put a stretch circuit in the firmware to give the > > resistors several us to pull the line up. > > I THINK both of your boards SHOULD have this feature, but > > I'm not totally sure. > > > I checked the firmware, and the ver 3 also has the 1 us > stretch on the come-out-of-estop pulse, so that should not > be the problem. > > Jon > > > ___ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > -- Matthew Herd Email: herd.m...@gmail.com Cell: 610-608-8930 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Problem with E Stop Logic
On 02/15/2021 10:56 AM, Jon Elson wrote: The very old boards only gave a few hundred ns for the resistor to pull the E-stop/ line up. If there was too much capacitive load on the cable, it would not rise enough and then the board would go back to E-stop. I put a stretch circuit in the firmware to give the resistors several us to pull the line up. I THINK both of your boards SHOULD have this feature, but I'm not totally sure. I checked the firmware, and the ver 3 also has the 1 us stretch on the come-out-of-estop pulse, so that should not be the problem. Jon ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Problem with E Stop Logic
On 02/15/2021 10:22 AM, Matthew Herd wrote: Great, I may not be able to get back to the machine to test until the weekend, but will update you as soon as I am able to test. But given the results I’ve seen with the sample config, I doubt it’ll work. Well, then something is broken. If it doesn't work, I'd disconnect the older board and try with just one. The two boards need to communicate over the short ribbon cable to share the E-stop state. Also, the watchdog timer should probably be turned off on the 2nd board. There was also an issue with the pull-up on the E-STOP line, I think I may have changed the pull-up resistors some time back to give a bit more pull-up, and added a delay. The very old boards only gave a few hundred ns for the resistor to pull the E-stop/ line up. If there was too much capacitive load on the cable, it would not rise enough and then the board would go back to E-stop. I put a stretch circuit in the firmware to give the resistors several us to pull the line up. I THINK both of your boards SHOULD have this feature, but I'm not totally sure. One trick is to intercept and break pin 13 between the USC board and the DB25 cable to the computer, but we ought to determine if that is actually the problem, first. Jon ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Problem with E Stop Logic
Great, I may not be able to get back to the machine to test until the weekend, but will update you as soon as I am able to test. But given the results I’ve seen with the sample config, I doubt it’ll work. > On Feb 15, 2021, at 10:43 AM, Jon Elson wrote: > > On 02/15/2021 05:21 AM, Matthew Herd wrote: >> Tying SSR8’s together should work fine for me, since I’ve wired the enables >> to the second board’s SSR8. Changing to dout.07 is easy enough. >> >> I don’t have the boards here to visually verify, but I did set switch 10 >> before installing. I also wired up the boards with the ribbon cable >> configured as you specified. Both boards show up using the diagnostics >> program’s bus display, with the second (older) board identifying as version >> 3, and the first board as version 5. On the HAL Configuration window, all >> pins from both boards enumerate as expected. >> >> > OK, then, when you have the univstep_io.hal file changed to send the > out-of-estop command to > dout.07, it ought to work, as long as none of the related addf's in > univstep_load.hal have been moved in the wrong order. If not, send me your > univstep_load.hal file, and I'll see if I can see what is wrong. But, > hopefully, it will just work. > > Jon > > > ___ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Problem with E Stop Logic
On 02/15/2021 05:21 AM, Matthew Herd wrote: Tying SSR8’s together should work fine for me, since I’ve wired the enables to the second board’s SSR8. Changing to dout.07 is easy enough. I don’t have the boards here to visually verify, but I did set switch 10 before installing. I also wired up the boards with the ribbon cable configured as you specified. Both boards show up using the diagnostics program’s bus display, with the second (older) board identifying as version 3, and the first board as version 5. On the HAL Configuration window, all pins from both boards enumerate as expected. OK, then, when you have the univstep_io.hal file changed to send the out-of-estop command to dout.07, it ought to work, as long as none of the related addf's in univstep_load.hal have been moved in the wrong order. If not, send me your univstep_load.hal file, and I'll see if I can see what is wrong. But, hopefully, it will just work. Jon ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Problem with E Stop Logic
Tying SSR8’s together should work fine for me, since I’ve wired the enables to the second board’s SSR8. Changing to dout.07 is easy enough. I don’t have the boards here to visually verify, but I did set switch 10 before installing. I also wired up the boards with the ribbon cable configured as you specified. Both boards show up using the diagnostics program’s bus display, with the second (older) board identifying as version 3, and the first board as version 5. On the HAL Configuration window, all pins from both boards enumerate as expected. > On Feb 14, 2021, at 10:40 PM, Jon Elson wrote: > > On 02/14/2021 09:03 PM, Matthew Herd wrote: >> Thank you Jon. So it’s impossible to reassign dout.15 to E-stop enable? >> I’m using the first board for the E-stop loop, but attempting to use dout.15 >> on the second board to enable my servo drives. > No, sorry, SSR8 on the second board is a slave to the first board, it will > always follow exactly what SSR8 on the master board does. That's just a > limitation of the way the E-stop logic was built. > I guess I wasn't thinking far enough ahead. >> I should also note, the sample doesn’t work either and it uses dout.07. >> Even though my e-stop loop is wired to din.15. >> > Well, now, that's odd. First, make sure you have DIP switch 10 ON for the > master board and OFF for the slave. How dod you connect the 2nd board? You > connect the DB-25 to one of the boards, and then connect a ribbon cable with > a DB25 on one end to the 2nd board's P1 and an IDC 26 pin connector to the > first board's P9. Is that what you have set up? Can you see both boards > show up on the univstepdiag program's bus display? > > Jon > > > ___ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Problem with E Stop Logic
On 02/14/2021 09:03 PM, Matthew Herd wrote: Thank you Jon. So it’s impossible to reassign dout.15 to E-stop enable? I’m using the first board for the E-stop loop, but attempting to use dout.15 on the second board to enable my servo drives. No, sorry, SSR8 on the second board is a slave to the first board, it will always follow exactly what SSR8 on the master board does. That's just a limitation of the way the E-stop logic was built. I guess I wasn't thinking far enough ahead. I should also note, the sample doesn’t work either and it uses dout.07. Even though my e-stop loop is wired to din.15. Well, now, that's odd. First, make sure you have DIP switch 10 ON for the master board and OFF for the slave. How dod you connect the 2nd board? You connect the DB-25 to one of the boards, and then connect a ribbon cable with a DB25 on one end to the 2nd board's P1 and an IDC 26 pin connector to the first board's P9. Is that what you have set up? Can you see both boards show up on the univstepdiag program's bus display? Jon ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Problem with E Stop Logic
Thank you Jon. So it’s impossible to reassign dout.15 to E-stop enable? I’m using the first board for the E-stop loop, but attempting to use dout.15 on the second board to enable my servo drives. I should also note, the sample doesn’t work either and it uses dout.07. Even though my e-stop loop is wired to din.15. > On Feb 14, 2021, at 9:47 PM, Jon Elson wrote: > > On 02/14/2021 08:02 PM, Matthew Herd wrote: >> I’ve been working on a new configuration using a fresh install from the live >> image for 2.8.0 and have had some trouble with my E Stop logic. I am using >> two Pico USC boards and a config based on the default USC with encoder >> sample. When I attempt to click the red button (F1 in Axis) the machine >> will not come out of E Stop. My E Stop logic is copied below. > My sample configs in the LinuxCNC distro have some functions that must be > done in the exact order for them to work. The critical part is the order of > addf calls in univstep_load.hal > With two USCs, only the one with the lower-numbered address (DIP switch #10 > ON) has control of the E-stop, and the other board acts as a slave. The > E-stop input on the 2nd board has no function. So, make sure the E-stop loop > is wired to the USC with DIP switch 10 ON. > > The way this works is it depends on the one servo cycle delay between writing > the request to come out of E-stop and the next servo cycle where it reads the > state of the E-stop and sees that it now shows OK status. If you have > changed the order of addf's in univstep_load.hal of any of the functions > connected in the block of univstep_io.hal you quoted, then try to get them > back in the same order as the sample config. > > OK, here's your problem: >> net EstopOkOut <= ppmc.0.dout.15.out > This is the 2nd USC board, which is NOT the master. The ppmc driver always > makes the lowest > numbered USC the master, so that must be ppmc.0.dout.07.out as that is the > digital output that commands the master board to come out of E-stop. The > equivalent digital output on the slave board has no function, it always > follows the master board. > > Jon > > > ___ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Problem with E Stop Logic
On 02/14/2021 08:02 PM, Matthew Herd wrote: I’ve been working on a new configuration using a fresh install from the live image for 2.8.0 and have had some trouble with my E Stop logic. I am using two Pico USC boards and a config based on the default USC with encoder sample. When I attempt to click the red button (F1 in Axis) the machine will not come out of E Stop. My E Stop logic is copied below. My sample configs in the LinuxCNC distro have some functions that must be done in the exact order for them to work. The critical part is the order of addf calls in univstep_load.hal With two USCs, only the one with the lower-numbered address (DIP switch #10 ON) has control of the E-stop, and the other board acts as a slave. The E-stop input on the 2nd board has no function. So, make sure the E-stop loop is wired to the USC with DIP switch 10 ON. The way this works is it depends on the one servo cycle delay between writing the request to come out of E-stop and the next servo cycle where it reads the state of the E-stop and sees that it now shows OK status. If you have changed the order of addf's in univstep_load.hal of any of the functions connected in the block of univstep_io.hal you quoted, then try to get them back in the same order as the sample config. OK, here's your problem: net EstopOkOut <= ppmc.0.dout.15.out This is the 2nd USC board, which is NOT the master. The ppmc driver always makes the lowest numbered USC the master, so that must be ppmc.0.dout.07.out as that is the digital output that commands the master board to come out of E-stop. The equivalent digital output on the slave board has no function, it always follows the master board. Jon ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] Problem with E Stop Logic
I’ve been working on a new configuration using a fresh install from the live
image for 2.8.0 and have had some trouble with my E Stop logic. I am using two
Pico USC boards and a config based on the default USC with encoder sample.
When I attempt to click the red button (F1 in Axis) the machine will not come
out of E Stop. My E Stop logic is copied below.
# connect e-stop write/sense to I/O controller
# and univstep's fault with estop's output, so estop FF is reset, but
# prevent continued estop signal from univstep from holding FF cleared
net ppmcEstop ppmc.0.din.15.in-not
net ppmcEstop and2.0.in0
net EstopOkIn estop-latch.0.fault-in
net EstopOkIn and2.0.out
net EstopOkOut <= ppmc.0.dout.15.out
net EstopOkOut iocontrol.0.emc-enable-in
net EstopOkOut estop-latch.0.ok-out
net EstopOkOut and2.0.in1
net emc-estop-out iocontrol.0.user-enable-out
net emc-estop-out estop-latch.0.ok-in
net emc-estop-reset iocontrol.0.user-request-enable
net emc-estop-reset estop-latch.0.reset
I’ve confirmed that my E-Stop OK light on the USC lights up when the E-Stop
switch is closed and the E-Stop OK light goes out when the E-Stop switch is
palmed down. I have also looked at the HAL configuration window and confirmed
that there are no internal or external conditions blocking a successful enable.
I was able to trace the issue to the estop-latch.0.reset pin not successfully
triggering an estop-latch.0.ok-in. Instead, I can clearly see the reset pin go
true when I click the button in the Axis GUI, but the state never changes. I
was able to bypass this using a simpler arrangement ("net estop-loop
iocontrol.0.user-enable-out iocontrol.0.emc-enable-in") that I pulled from a
sim config. Neither the Pico USC example nor my config based on that example
will come out of E Stop.
Does anyone have any ideas for why the estop-latch would refuse to give an
ok-in when all conditions are met per the manual?
http://www.linuxcnc.org/docs/html/man/man9/estop_latch.9.html
Thanks,
Matt
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
