Back
[07:48:54] * JT-Shop wonders if we should have a Pico and Mesa section?
[07:53:51] <JT-Shop> does this mean anything? emc/task/emctaskmain.cc:342:18: warning: ignoring return value of ‘int setuid(__uid_t)’, declared with attribute warn_unused_result [-Wunused-result]
[07:53:51] <JT-Shop> setuid(getuid());
[07:53:52] <JT-Shop> ^
[07:57:36] <cncbasher> nope it's only a warning, errors are the ones to look out for
[07:59:09] <JT-Shop> ok thansk
[07:59:57] <cncbasher> whats the problem jt ?
[08:04:48] <JT-Shop> nothing just noticed that when installing linuxcnc on linuxmint
[08:05:54] <cncbasher> arh ok , yes you'll get a list of warnings , usually you can discard them, it really means it knows of a potential problem , but knows how to get round it
[08:06:21] <cncbasher> errors are more serious and will stop a build
[08:07:01] <cncbasher> not all warnings are problems either , especially when say your building across different platforms
[08:07:03] <JT-Shop> lol my step by step was out of date now it is 2.7.3
[08:07:53] <cncbasher> so if your building on a pc for example, it will error on code meant for say a beaglebone ,
[08:08:27] <JT-Shop> ah ok
[08:08:37] <JT-Shop> LinuxCNC up and running now :)
[08:17:18] <cncbasher> debian 8 now has mint as a gui
[08:19:56] <JT-Shop> I noticed mate on wheezy is not as good as mate on linuxmint... is wheezy 7?
[08:20:41] <JT-Shop> is there some problem with debian 8 and rtai or something like that?
[08:21:08] <JT-Shop> should be some bacon on the stove so I'm heading in
[08:23:00] <cncbasher> not sure i'm just getting to that point building the rtai kernel to try , i'll let you know
[08:46:23] <Tom_itx> maybe they should give linux ver numbers instead of names
[08:47:09] <cncbasher> yea it does get a bit long winded,working with numbers
[08:48:14] <cncbasher> i,m having fun with a 7i90 that wont flash the eeprom
[08:48:25] <Tom_itx> i have a wiki for that
[08:48:46] <Tom_itx> or similar
[08:48:58] <cncbasher> i had to jtag the main bit file , but the fallback is being a pain
[08:49:12] <Tom_itx> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Recover_Corrupt/Blank_EEPROM_5i24%2C6i24%2C7i24%2C_6i25
[08:49:45] <Tom_itx> you don't have to jtag the main bitfile now
[08:49:51] <cncbasher> why set up as a 6i25
[08:50:03] <Tom_itx> that's how the mesaflash sees them
[08:50:17] <Tom_itx> it does work though, i've got a 7i90 i recovered
[08:50:29] <cncbasher> mesaflash dont pick up on the board
[08:50:36] <Tom_itx> not yet
[08:50:55] <Tom_itx> micges added this for me a while back
[08:51:08] <cncbasher> ok i'll try setting as a 6i25 , thats the only part iv'e not tried
[08:51:26] <cncbasher> i'm using the latest mesaflash
[08:51:33] <Tom_itx> right
[08:51:36] <cncbasher> as per his repro
[08:51:51] <Tom_itx> no new ones since this that i'm aware of
[08:52:19] <cncbasher> the secondary eeprom will boot
[08:52:42] <cncbasher> but the first wont , due to a programming error
[08:52:56] <Tom_itx> you may ask pcw about it
[08:53:10] <cncbasher> so i booted using the second prom ,then changed the link back
[08:53:20] <Tom_itx> yeah i had the wrong chip selected once when i did my bitfile
[08:53:23] <Tom_itx> corrupted it
[08:54:00] <cncbasher> then i should be able to flash the fallback , but mesaflash just dont see the 7i90 at all ,
[08:54:13] <cncbasher> i was hoping to flash via the jtag
[08:54:21] <Tom_itx> this should work but if it doesn't you may have other issues
[08:54:33] <cncbasher> but you need the epprom size
[08:55:09] <cncbasher> thanks anyhow
[08:55:24] <Tom_itx> i got a jtag for mine but never needed to use it after using mesaflash
[08:55:53] <Tom_itx> can't help you there
[08:56:17] <cncbasher> haha no worries , just 2 heads sometimes are better than one
[08:56:38] <Tom_itx> make sure the fpga size as well
[08:56:42] <cncbasher> i recovered a cpld using your method , that was a great help
[08:56:51] <Tom_itx> there are 2 sets of files iirc for it
[08:56:58] <cncbasher> but an absolute nightmare replacing the chip haha
[08:58:02] <Tom_itx> there are likely more since it has 3 different interfaces
[08:59:20] <cncbasher> yea ive created my own for epp , but i might try the serial and see if i can find life
[08:59:36] <Tom_itx> does it show up in dmesg?
[09:01:37] <cncbasher> i dont think so
[09:02:01] <cncbasher> i'll dig it out in an hour and have a look , once this has stopped compiling
[09:03:43] <cncbasher> thanks , i'll let you know if i get anywhere it may be useful to knwo
[09:41:40] <KGB-linuxcnc> 03Jeff Epler 05master 5f9f789 06linuxcnc 10src/emc/task/emctaskmain.cc task: remove vestige of setuid task support * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5f9f789
[09:42:07] <jepler> That setuid() call is a security-important call, so some compilers warn if its return value is ignored.
[09:42:56] <jepler> The call is there to support running task as a different user than user-defined m-codes, but in linuxcnc we have never had task running as a different user
[09:42:59] <jepler> so I removed it
[09:44:07] <jepler> it could also have been fixed by writing if(setuid(...) != 0) { print an error and exit; }
[09:44:22] <jepler> but .. it should just be removed
[09:44:27] <cncbasher> thanks for that snippet
[09:44:49] <cncbasher> easier to get rid of clutter if we dont need it
[09:47:55] <jepler> http://mlkshk.com/r/16CGT
[09:52:37] <archivist> you just incremented it a bit more :)
[09:55:08] <jepler> google n-gram viewer tells a different story
https://books.google.com/ngrams/graph?content=exponential+growth
[09:55:20] <jepler> but the gif is awfully truthy
[10:11:07] <pcw_home> cncbasher: if current mesaflash does not work on a 7I90 after JTAG loading the FPGA ( _NOT_ the EEPROM )
[10:11:08] <pcw_home> with a EPP config, you have a problem with your EPP interface, either on the PC or the 7I90 (damaged FPGA?)
[10:18:33] <cncbasher> hi , yea i'm looking at the pc interface
[10:18:42] <cncbasher> i doubt it's the fpga
[10:19:08] <cncbasher> as it was all working before , the re-flashing
[10:20:02] <cncbasher> i'd like at least one interface of epp,rs422 etc to give me something
[10:21:24] <cncbasher> as even now my 7i43's packed up , after changing the cpld
[10:21:30] <pcw_home> it was working before on the same parallel port?
[10:21:45] <cncbasher> i think it's just lifted the track , but i'll bin it
[10:23:29] <cncbasher> no thats my problem , i dont have a machine that worked , hence waiting for the 7i76e
[10:24:02] <cncbasher> i could reflash the 5i25 to a parallel port i presume
[10:24:24] <cncbasher> it's not my month lol !
[10:24:44] <cncbasher> how your on the mend too
[10:24:47] <cncbasher> hope
[10:28:47] <cncbasher> i was hoping, if i could use the windows pc to flash it.
[10:42:22] <cncbasher> iv'e just tried it now
[10:42:52] <cncbasher> using sudo mesaflash --device 7i90 --readhmid
[10:43:29] <cncbasher> epp timeout on data cycle of read (addr=0x0000, size=4)
[10:43:47] <cncbasher> same again 0x0100
[10:44:01] <cncbasher> no 7i90 board found
[10:45:29] <pcw_home> If the 7I90 nis OK, that suggests that the parallel port address is wrong, or the parallel port is not set into EPP mode (or theres a cable issue)
[10:46:16] <cncbasher> ok i'll hunt further in that direction
[11:03:58] <seb_kuzminsky> something changed in the past day or two, and now i get an email for each forum post, it says "A new post has been made to a category to which you have assigned as moderator on the LinuxCNC"
[11:04:08] <jepler> seb_kuzminsky: yes
[11:04:18] <JT-Shop> lol
[11:04:26] <jepler> seb_kuzminsky: I've enabled moderation of the first posts by new users
[11:04:44] <seb_kuzminsky> ah, ok
[11:04:47] <jepler> those posts are held for moderation, and mail(s) are generated
[11:05:05] <seb_kuzminsky> so i could contribute by logging in and clicking OK if it's not spam?
[11:05:07] <jepler> possibly to everyone, though it says in the mail you've been "selected" to moderate the post
[11:05:11] <jepler> right
[11:05:11] <JT-Shop> nip them spammers at the start
[11:05:27] <jepler> that's the theory
[11:05:36] <jepler> if it's too irritating to pre-moderate those first posts I can turn it back off
[11:05:45] <seb_kuzminsky> i think it's a good idea
[11:05:59] <jepler> I'm not sure who all gets the moderation messages either
[11:06:06] <jepler> I think it sends it to more than one victim
[11:06:13] <jepler> possibly all the admins are getting them .. ?
[11:13:51] <JT-Shop> I think it is a good idea as well
[12:21:34] <cncbasher> is RTAI rt running on linuxcnc i.e not rt-preempt or zenomai , or am i stuck , i,m lookiing for a guarenteed working rtai for wheezy
[12:33:58] <jepler> our wheezy iso and regular wheezy install instructions give you an RTAI kernel that works on a reasonably wide range of x86 PCs. Or maybe I'm misunderstanding the question.
[12:38:49] <cncbasher> i am been continualy told that 3.4.9 is not usable
[12:40:10] <jepler> That's the only RTAI kernel that linuxcnc.org has prepared for debian wheezy.
[12:40:15] <mozmck> on the forum? I haven't heard that - and I know that it is being used.
[12:40:18] <cncbasher> or to be more precise , my requirement is epp
[12:41:51] <cncbasher> ok i'll dig deeper as to why i cant get epp working , i just seem to be going round in circles LOL
[12:42:57] <jepler> It's the first I've heard that specifically EPP hardware support is worse on Wheezy+rtai than other setups.
[12:43:55] <cncbasher> i'm trying to pin a problem down, thats all
[12:44:19] <cncbasher> this pc ran fine up to 3.4.9
[12:45:47] <cncbasher> so i;m not in the point of not knowing if it's hardware or other , thats stopping it working
[12:46:15] <cncbasher> works fine with a standard parallel port
[12:46:24] <cncbasher> but not epp
[12:47:26] <cncbasher> i'll dig a bit deeper LOL
[12:53:05] <pcw_home> I've run the 7I90 (EPP) with stock Wheezy RTAI
[13:00:10] <cncbasher> ok thanks
[13:00:49] <cncbasher> i'll dig into these pci cards a bit more
[13:01:43] <cncbasher> i cant even get the onboard lpt working either, which did work before 3.4.9
[13:07:36] <mozmck> I've got a strange problem or two here. I'm trying to add an INI setting in the EMCMOT section to disable certain probe errors. The variable gets set properly, but it seems to ignore the variable and run the code anyhow. diff here:
http://pastie.org/10611757
[13:07:47] <mozmck> against current 2.7 branch
[13:10:20] <mozmck> I added code to print the value of inhibit_probe_errors just before and after the inifile.Find(...) call, and it prints 0 before and 1 after.
[13:10:40] <mozmck> Any idea what I'm missing here?
[13:21:35] <cncbasher> i think you'd be better with it in iocontrol.cc
[13:23:14] <cncbasher> their are a number of paths the code runs , not all are obvious , and some are not picked up at runtime
[13:24:17] <cncbasher> could you not place a relay across the probe , and trigger that when it's needed
[13:24:18] <jepler> mozmck: I think that usrmotintf.cc is code in the userspace process milltask, and control.c is in the realtime component motion
[13:24:47] <jepler> so the global variable inhibit_probe_errors refers to different things in those two different sites
[13:24:57] <cncbasher> so when the probe is not needed it's essentialy shorted out
[13:31:39] <cncbasher> jepler: do we have a probe inhibit pin ?
[13:33:38] <jepler> cncbasher: I think the traditional advice has been in two parts, (A) we think the probe mask feature will probably destroy probes, so we're not thrilled about it and (B) you can already probe signal masking in HAL, such as with an and2 component.
[13:36:25] <cncbasher> yea thats what i was thinking for machines with high noise probability such as plasmas etc , i usually just fit a relay , but being able to mask , should do the same
[13:36:52] <JT-Shop> I use the probe input on my plasma with a micro switch as the probe
[13:37:01] <jepler> and I have never used such high-noise machines
[13:37:52] <cncbasher> youv'e never lived ,unless your whole workshop is ablaze with electrical noise !
[13:37:56] <jepler> it makes me wonder how you can reliably do *anything*. do you get spurious steps generated at the same rate as spurious probe inputs?
[13:38:37] <jepler> but if I understand this case, it's specifically that the Z home switch and the probe have to share a physical input for hardware reasons..?
[13:39:45] <cncbasher> then a simple or2 should work
[13:40:26] <cncbasher> you could then use a macro to turn on or off the inhibit
[13:41:26] <cncbasher> as you'd probably never probe during a G0 move then inhibit it
[13:50:33] <mozmck> jepler: that may be the problem - if I want to do this I may need to figure out how to get the variable across the realtime divide.
[13:51:35] <cncbasher> what type of probe are you using ?
[13:52:02] <mozmck> I'm currently using a setup in hal to only enable the probe input when probing. The only problem is that if you do a G38.2 without first calling M64 to enable the probe, it simply crashes and keeps going until something breaks.
[13:52:29] <mozmck> It's either a micro switch on the Z or an ohmic sensor.
[13:52:49] <cncbasher> with a pullup to say 5v ?
[13:53:11] <mozmck> something like that.
[13:54:21] <cncbasher> sometimes a opto in the line , can cure small spikes or a debounce
[13:54:47] <cncbasher> without interfering with sense time
[13:55:15] <mozmck> I'm not having problems with spikes or bounce. I simply don't want it to error if you jog down and touch the metal - or when homing.
[13:55:19] <cncbasher> and of course using good sheilded cable for the prode
[13:55:22] <cncbasher> probe
[13:55:41] <cncbasher> understood
[13:58:11] <cncbasher> could you not catch the g38.2 in a macro and add the m64
[13:58:38] <mozmck> We have customers that already have code that works using a G38.2 in the gcode - which is why I'm looking at adding the option to inhibit those errors. If I update them with the hal setup they will have to be careful to not use their existing code without updating it.
[13:58:50] <mozmck> how would I catch g38.2?
[14:01:56] <mozmck> jepler: another issue I'm having is that if I use my o<touchoff> routine, run from line seems badly broken. I can take the code from the routine, copy it into the gcode instead of using the o<touchoff> call, and run from line works.
[14:04:05] <mozmck> But since I have an if ... else statement in the routine, and those require o numbers (why???), I can't just copy the code, I have to change the oXX number for each if statement to avoid duplicate o number errors.
[14:04:57] <jepler> I don't have a lot of positive defense of O-words or RFL to share with you.
[14:05:24] <mozmck> cncbasher: if you mean that I can put the m64 and g38.2 in a subroutine - that's what I did.
[14:06:28] <mozmck> jepler: :-) It looks to me like the line numbers are getting garbled or something.
[14:06:41] <cncbasher> yes , unfortunatly you can't guard against all human error
[14:08:31] <cncbasher> unfortunatey theirs more than one track for the interpretors , some are more instant than others
[14:08:39] <mozmck> no, but the more we can do, the less time we will have to spend on support calls.
[14:09:12] <cncbasher> yea indeed
[14:09:16] <mozmck> not sure I understand that - "track for the interpretors"?
[14:10:07] <cncbasher> the gcode as read and parsed has more than one route
[14:12:02] <mozmck> O-words can definitely complicate things.
[14:12:03] <cncbasher> it's actualy a nightmare to follow
[14:12:34] <mozmck> yes, seems like it. I think some of that has to do with the evolution of the code over time too.
[14:13:13] <cncbasher> i'm just about getting their after looking at it for 3 years
[14:13:51] <cncbasher> it's also the least documented
[17:56:37] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes9 5d133b2 06linuxcnc 10docs/man/man1/linuxcncrsh.1 10docs/src/getting-started/updating-linuxcnc.txt 10src/emc/usr_intf/emcrsh.cc linuxcncrsh (emcrsh.cc): update for joints_axes * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5d133b2
[17:56:37] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes9 b692997 06linuxcnc 10(5 files) usr_intf/ consolidate JOGJOINT,JOGTELEOP defines * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b692997
[18:40:14] <linuxcnc-build> build #1568 of 4017.deb-wheezy-amd64 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-amd64/builds/1568 blamelist: Dewey Garrett <dgarrett@panix.com>
[19:12:19] <KGB-linuxcnc> 03Chris Morley 052.6 e9d6ff5 06linuxcnc 10lib/python/gladevcp/offsetpage_widget.py gladevcp -offset_widget: fix rare error of non-existant var file * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e9d6ff5
[19:12:19] <KGB-linuxcnc> 03Chris Morley 052.6 08a2b46 06linuxcnc 10share/gscreen/skins/industrial/industrial.glade Gscreen: fix industrial skin's A axis DTO readout * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=08a2b46
[19:13:33] <KGB-linuxcnc> 03Chris Morley 052.7 73c3ae8 06linuxcnc 10share/gscreen/skins/industrial/industrial.glade Merge branch '2.6' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=73c3ae8
[19:15:05] <KGB-linuxcnc> 03Chris Morley 05master 58ab506 06linuxcnc Merge branch '2.7' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=58ab506
[19:26:43] <seb_kuzminsky> mozmck: if your goal is to have motion only pay attention to the probe input while in a probing move, take a look at motion.motion-type
[19:27:22] <seb_kuzminsky> the motion.probe-input pin could get (gpio input connected to probe AND (motion-type == 5))
[19:27:52] <seb_kuzminsky> it might make sense to split motion.motion-type up into a bunch of bool pins, motion.motion-type-travers, motion.motion-type-probe, etc
[20:27:07] <mozmck> seb_kuzminsky: that's may be a good idea - thanks!
[21:26:39] <linuxcnc-build> build #3714 of 1200.rip-lucid-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1200.rip-lucid-i386/builds/3714 blamelist: Chris Morley <chrisinnanaimo@hotmail.com>
[22:06:05] <linuxcnc-build> build #3727 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3727 blamelist: Chris Morley <chrisinnanaimo@hotmail.com>