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] hal_pi_gpio man page
I like your comments throughout. Gives me a feel of the why or what you were
trying to accomplish rather than something like
a = 5; // assign 5 into variable a.
Being nit picky I'd have done the following with the opposite logic.
// --- beg --- create & export hal_pins
for (n = 0; n < npins; n++) {
if( pinarray[n].gpionum ){
// NADA fall into ensuing code
}else{ /* this pin is not used so skip to top of loop */
continue;
}
Prevents the imperceptible pause while reading the text causing one to stop,
move up a few lines lines and go "Ah. The pin was 0 so not used. That's what
he's doing"
// --- beg --- create & export hal_pins
for (n = 0; n < npins; n++) {
if( pinarray[n].gpionum == 0 ){
continue; // this pin is not used so skip to top of loop
}
Are you going to be able to link SPI or I2C to this or maybe even socketCAN via
SPI based MCP2515 devices? Is that even possible in the HAL?
Other than that from a documentation perspective I'd like to see a bit more why
something is done. For example:
int get_initial(char * cp) {
Searched the entire file. No other function calls this. So it must be
required for a component? In which .h file is it exported. Yes. I can find
those files and look in each one to find out if it's even declared as global.
A header in the function that states where it's exported and why or who would
call it and when. I'm guessing cp means character pointer?
My comments are based on not knowing how to write a component and not knowing
what's needed.
Great job otherwise.
John
> -Original Message-
> From: Thomas J Powderly [mailto:tjt...@gmail.com]
> Sent: February-16-21 7:49 AM
> To: emc-develop...@lists.sourceforge.net; emc-users@lists.sourceforge.net
> Subject: [Emc-users] hal_pi_gpio man page
>
> The hal_pi_gpio component seems to be beta stage
> meaning I don't see anything wrong.
> When I programmed full-time this was when I had to hand it over to
> others to peer.
>
> Where do I look for howto write a man page?
>
> About the comp -
> Written in old-school c
> For rpi's only
> ( so far anyway, the scheme is flexible for similar, opi bpi maybe bbb
> bbw bbg )
>
> It's real-time ( well it starts with� loadrt under userspace linuxcnc
> tested on rpi33 )
> It only needs 1 thread and has re-settable pins
> ( and has a setp'able param reset_time ,
> � set in integer of nS units (up to 1/4 thread period))
> It has inputs and in-nots
> It has outputs and out-inverts and out-resets
> It uses a man readable config format ( a teeny language to describe each
> pin , see end of msg)
> It reads switches and blinks leds
> ( an old boss assured me more blinky lights was a good thing )
>
> I can send a copy to anyone wanting to try, hell its text, see attachment.
>
> How to build in a rip installation:-
> I compile it by backing up the hal_pi_gpio.c in my rip directory
> � ~/linuxcnc-dev/src/hal/drivers/hal_pi_gpio.c� (move to another dir,
> don't just rename it)
> then copying my file into there using the same name as the pi gpio.c
> file that was there before.
>
> Then touch it (to insure it is changed so make will notice and rebuild it )
> �type�� touch hal_pi_gpio.c�� in the src/hal.driver dir
>
> Then make modules�� from the ~/linuxcnc/src�� dir
> (this trickery is due to the .c file
> �needing other .c files in that dir,
> �and a simple gcc command is beyond my ken )
> I get no errors no notes no warnings, its a clean make here
>
> Once it makes, you use it with halrun like this
>
> halrun
> loadrt hal_pi_gpio pi_pins={03,<,+,x}{05,>,1,Y}{07,>,0,}{40,>,1,Y}
> loadrt threads name1=slow period1=15
> addf hal_pi_gpio.read slow
> add hal_pi_gpio.write slow
> addf hal_pi_gpio.reset slow
> setp hal_pi_gpio.reset_time 3 (easier to see than my 2000)
> start
>
>
> Then use show pin and show param to watch things work
> (and halmeter and halscope too)
>
> You'll need a scope to catch the reset pins.
>
> They change inside one thread period so halscope cant see 'em.
>
> Hook up a bread board and switches and leds ( 3.3V i/o here!!)
>
> ( as simple as hooking up an output to an input will show you something )
>
> About the pi_pins config
> line--
> It's simple but strict rules
> Each pin is described by a 'quad' ( a 4 param thingy )
> Each quad has the format _like_
> {03,>,0,N}
> This describes the rpi header pin#3
> and is an output ( the '>' is used for out )
> and has an initial power on value of 0 ( zero )
> and does NOT have a reset feature
> {05,>,1,Y}
> ��� describes header pin 5
> ��� which is an output '>'
> ��� and has intial value of 1
> ��� and has the reset feature ( requires set hal_pi_gpio.reset_time
> 2000 for 2us example)
> {07,<,+,x}
> ��� describes header pin 7
> ��� which is an input
> ���
[Emc-users] hal_pi_gpio man page
The hal_pi_gpio component seems to be beta stage
meaning I don't see anything wrong.
When I programmed full-time this was when I had to hand it over to
others to peer.
Where do I look for howto write a man page?
About the comp -
Written in old-school c
For rpi's only
( so far anyway, the scheme is flexible for similar, opi bpi maybe bbb
bbw bbg )
It's real-time ( well it starts with loadrt under userspace linuxcnc
tested on rpi33 )
It only needs 1 thread and has re-settable pins
( and has a setp'able param reset_time ,
set in integer of nS units (up to 1/4 thread period))
It has inputs and in-nots
It has outputs and out-inverts and out-resets
It uses a man readable config format ( a teeny language to describe each
pin , see end of msg)
It reads switches and blinks leds
( an old boss assured me more blinky lights was a good thing )
I can send a copy to anyone wanting to try, hell its text, see attachment.
How to build in a rip installation:-
I compile it by backing up the hal_pi_gpio.c in my rip directory
~/linuxcnc-dev/src/hal/drivers/hal_pi_gpio.c (move to another dir,
don't just rename it)
then copying my file into there using the same name as the pi gpio.c
file that was there before.
Then touch it (to insure it is changed so make will notice and rebuild it )
type touch hal_pi_gpio.c in the src/hal.driver dir
Then make modules from the ~/linuxcnc/src dir
(this trickery is due to the .c file
needing other .c files in that dir,
and a simple gcc command is beyond my ken )
I get no errors no notes no warnings, its a clean make here
Once it makes, you use it with halrun like this
halrun
loadrt hal_pi_gpio pi_pins={03,<,+,x}{05,>,1,Y}{07,>,0,}{40,>,1,Y}
loadrt threads name1=slow period1=15
addf hal_pi_gpio.read slow
add hal_pi_gpio.write slow
addf hal_pi_gpio.reset slow
setp hal_pi_gpio.reset_time 3 (easier to see than my 2000)
start
Then use show pin and show param to watch things work
(and halmeter and halscope too)
You'll need a scope to catch the reset pins.
They change inside one thread period so halscope cant see 'em.
Hook up a bread board and switches and leds ( 3.3V i/o here!!)
( as simple as hooking up an output to an input will show you something )
About the pi_pins config
line--
It's simple but strict rules
Each pin is described by a 'quad' ( a 4 param thingy )
Each quad has the format _like_
{03,>,0,N}
This describes the rpi header pin#3
and is an output ( the '>' is used for out )
and has an initial power on value of 0 ( zero )
and does NOT have a reset feature
{05,>,1,Y}
describes header pin 5
which is an output '>'
and has intial value of 1
and has the reset feature ( requires set hal_pi_gpio.reset_time
2000 for 2us example)
{07,<,+,x}
describes header pin 7
which is an input
and has an in-not pin due to '+'
and the last param is meaningless, tested lightly with a few single
chars in that place
{12,<,-,x}
describes header pin 12
which is an input
and does not get an in-not pin , due to '-'
and last parm is meaningless
hokay
I am sure i didn't write near 1000 lines w/o mistakes
lemmeno
tomp
/
* 15feb2021
* compiles clean no errs not notes no warnings
*
* resets seems to work need scope trap to be sure
* scope can see 2uS pulse on step pins but halscope cannot
*
* i now have a param hal_pi_gpio.reset_time and i can setp it
* ( halrun show param shows in hex but ok its alive)
* TODO i can setp it but i suppose a default is good ideA
*
*/
#include "rtapi.h" /* RTAPI realtime OS API */
#include "rtapi_bitops.h"
#include "rtapi_app.h" /* RTAPI realtime module decls */
/* this also includes config.h */
#include "hal.h" /* HAL public API decls */
#include "bcm2835.h"
#include "cpuinfo.h"
#define BCM2708_PERI_BASE 0x2000
#define BCM2708_GPIO_BASE (BCM2708_PERI_BASE + 0x20)
#define BCM2709_PERI_BASE 0x3F00
#define BCM2709_GPIO_BASE (BCM2709_PERI_BASE + 0x20)
//#define RTAPI
#define RTAPI_BIT(nr) (1UL << (nr))
#include
#include
#include
#include/* for printf key chars*/
#include
#include
#include
#include
#include
#include
/*---*/
/*--beg-new arrays --*/
// i use an array witj entries for npiuns+1 0 thru and includiong npins like 0thru26 for old pi's and 0thru41 for 'new'er pis
these arrays can be used to lookup gpionum for rpi2 using hdrpinnum as index, a value of 0 means the pin is NOT available for gpio
// Rev 1 Raspberry: only 26 hdr pins for rpi rev2
static unsigned char nurev1_gpios[] =
{0, 0, 0, 0, 0, 1, 0, 4,14, 0,15,17,18,21, 0,22,23,
Re: [Emc-users] dynamic glade ui's
> On 15 Feb 2021, at 23:12, Ralph Stirling > wrote: > > > Is this possible? Any suggestions or examples to help? I think that you can do anything you want to the widgets via the usual Gtk(?) interface. I have certainly moved widgets around inside a Glade tab using the python handler code. Axis itself hides and shows spindle and coolant buttons based on parsing the Hal file. Once you have the handle to the top level container you can find widgets by name and do anything you want to them. Or, you could create widgets from scratch Gtk != Glade. Or you could use QTVcp or QTPyVCP. ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
