Back
[07:26:15] <jthornton> I'll try and get a RIP setup today and test the patch... I think I know how to create a sserial error
[07:30:42] <KGB-linuxcnc> 03John Thornton 052.7 1c18b1b 06linuxcnc 10docs/src/config/images/emc2-motion-homing-diag.dxf 10docs/src/config/images/emc2-motion-homing-diag.png Docs: update dxf and image * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1c18b1b
[08:23:00] <jepler> seb_kuzminsky: I don't have the necessary equipment to test
[08:23:07] <jepler> I imagine pcw_home does
[08:23:54] <jepler> .. I don't think that patch is a complete resolution of the problem, it just ignores one kind of error, the one with binary value 0x80.
[08:46:12] <JT-Shop> seb_kuzminsky: I still get a slew of sserial errors in 2.7 after trying the patch
[08:52:07] <micges> JT-Shop: have you tried different LPT cable?
[09:02:45] <JT-Shop> I only have the Mesa IEEE cable, no spares atm but I have some on the way
[09:10:16] <JT-Shop> also I'm not the only one with sserial problems in 2.7
[09:20:49] <micges> I know
[09:24:29] <micges> JT-Shop: got link to the errors you have?
[09:28:48] <JT-Shop> http://gnipsel.com/files/bp/BP1-6-16.txt
[09:31:00] <skunkworks> zlog
[09:35:36] <micges> JT-Shop: log changed after you applied patch?
[09:42:18] <micges> JT-Shop: sserial firmware is at v43 now, you have v38
[09:43:16] <micges> you should flash 5i25 with newest firmware first and check again
[09:43:29] <JT-Shop> sorry that is from last week
[09:43:37] <JT-Shop> I'll have to do it again
[09:48:42] <JT-Shop> http://gnipsel.com/files/bp/BP%201-12-16.txt
[09:50:40] <pcw_home> is that with 77f.bit?
[09:58:54] <JT-Shop> no, that's with 5i25_7i77x2mev4.bit
[10:07:53] <pcw_home> I would definately use 77f.bit if you have noise issues (it doesn't fix the 2.7 issue but will reduce impulse noise sensitivity somewhat)
[10:10:05] <skunkworks_> skunkworks@skunkworks-Studio-XPS-1645:~/linuxcnc-dev$ git pullYour configuration specifies to merge with the ref 'panelui'from the remote, but no such ref was fetched.
[10:11:02] <JT-Shop> I'll give 77f.bit a try when I get back from town, gotta take the van in to get new wheel bearings
[10:11:38] <jepler> skunkworks_: I believe that cmorley merged panelui to master branch and deleted the panelui branch
[10:11:55] <skunkworks_> ooh
[10:12:19] <jepler> $ git log origin/master --grep=panel -1 --oneline
[10:12:19] <jepler> 7715856 sim config: add a sample sim config for panelui
[10:15:21] <pcw_home> I have a cheapo test fixture idea for generating sserial errors
[10:17:01] <skunkworks> jepler, yep - that worked
[10:17:09] <skunkworks> cmorley, runs much better now.
[10:17:12] <skunkworks> cool setup
[10:18:18] <pcw_home> setup a stepgen for generating say a ~100 hz pulse train with maybe 1 usec width
[10:18:20] <pcw_home> set polarity for active low, then short FPGA step pin to sserial pin at FPGA
[10:18:50] <pcw_home> ( forgot to say set step output for open drain mode)
[10:19:08] <jepler> cute
[10:20:32] <pcw_home> better still (but more work) would be to integrate it into a test config
[10:33:54] <micges> JT-Shop: try this one
[10:35:16] <micges> JT-Shop:
http://pastebin.ca/3329543
[12:16:06] <micges> zlog: a
[12:16:58] <micges> logger[psha]_: hi
[12:16:58] <logger[psha]_> micges: Log stored at
http://psha.org.ru/irc/%23linuxcnc-devel/2016-01-12.html
[12:24:50] <JT-Shop> micges: same error with 0xFF00E12F, I'll try 77f.bit in a bit
[12:29:38] <skunkworks> pcw_home, when are you expecting the 7i77 in stock?
[12:31:57] <pcw_home> probably a couple weeks, being built now
[12:34:20] <skunkworks> thanks
[12:43:41] <pcw_home> JT-Shop: you should not be able to get any extra character errors with that mask so if you do,
[12:43:42] <pcw_home> either the patch didn't apply, you are not running what you think you are, or there something
[12:43:44] <pcw_home> else weird going on
[15:10:08] <CaptHindsight> how do I take a parameter like max spindle accel/decel (setp spindle-ramp.maxv) and not make it a constant in my HAL file but something I can set on a GUI?
[15:10:22] <CaptHindsight> Is there an example somewhere of something similar?
[15:11:35] <cradek> the gui panels present hal pins - you just hook them up
[15:11:55] <jepler> if it's a parameter, the right thing to do is convert it to a pin. In a .comp file this is typically easy; in a .c file it can be trickier.
[15:12:15] <CaptHindsight> thanks I'll take a look
[15:12:20] <cradek> oh right - only works for pins
[15:12:57] <jepler> some people have written terrible things for which they should feel bad, which internally invoke the moral equivalent of halcmd setp based on actions in the GUI
[15:13:34] <CaptHindsight> I need to be able to adjust the ramp up and down for spindle rpm based on what is going into the spindle
[15:14:10] <CaptHindsight> I'll have to dig int this since I'd also like the ramps to be non-linear
[15:14:24] <cradek> 51 float OUT 70 probe.probe_travel-f
[15:14:24] <cradek> 51 s32 OUT 70 probe.probe_travel-s
[15:14:41] <cradek> the gladevcp/probe sample config has some numeric parameters
[15:14:57] <CaptHindsight> or maybe linear but with two or three rates
[15:15:33] <jepler> CaptHindsight: you may just want to code your own ramping component from scratch, it sounds like much about limit2 (except that it is written) is good for you
[15:15:48] <cradek> er the full config name is sim/axis/gladevcp/probe
[15:15:48] <jepler> http://linuxcnc.org/docs/html/hal/intro.html#_hal_concepts
[15:15:54] <CaptHindsight> thanks
[15:16:47] <jepler> this tries to describe what the division between pin and parameter is supposed to be, but it turns out that the component author's prediction of *what* needs to be connected is always wrong
[15:17:00] <CaptHindsight> heh
[15:19:22] <jepler> I think part of the original design, which was never fully realized, included a way for the adjustment of a parameter to perform a possibly lengthy process like generating a lookup table -- things that might not be possible in the realtime execution context.
[15:20:49] <cradek> there sure may be coded-in assumptions that parameters don't change during runtime, and you might have problems if you uncarefully change parameters to pins without studying the use of the parameter
[15:22:37] <CaptHindsight> for example 0-500rpm 100rpm/sec, 500-2krpm 500rpm/sec, 2k-8krpm, 1krpm/sec
[15:22:49] <jepler> we have certainly seen bugs converting parameters to pins before. based on that experience, we wouldn't take such a conversion in a stable release branch without real strong motivation
[15:23:29] <cradek> limit3 might be one of those kinds, actually - I bet tighetning the constraints during ramping could cause violations
[15:23:43] <jepler> yeah that rings a bell actually
[15:24:14] <cradek> our previous problems were all "how do you even C" and not even what I'm worrying about here
[15:24:17] <jepler> I have a vague recollection that I could get it to oscillate by lowering the acceleration when it was in a cruise phase
[15:25:29] <CaptHindsight> I'll play with it and see how it goes
[15:30:18] <jepler> for instance, when I change limit3's maxa to .9 it can run away:
https://emergent.unpythonic.net/files/sandbox/limit3-runaway.png
[15:34:45] <jepler> (the back of my envelope is only telling me lies, but apparently 34 is the least maxa that can track siggen at 2 P-P and 1Hz)
[16:52:51] <JT-Shop> hmm after making the change make is ending oddly and I don't see any errors
[16:53:26] <JT-Shop> did a make clean... we will see
[18:00:09] <JT-Shop> here is the output from make with an error at the end
http://paste.ubuntu.com/14481919/
[18:08:42] <JT-Shop> I have ubuntu 10.04 on that machine if that makes any difference
[18:24:45] <micges> it builds here on ubu 10.04
[18:25:10] <JT-Shop> I'll get a fresh copy in the morning and try again
[18:25:12] <JT-Shop> thanks
[18:25:27] <micges> ok
[18:25:51] <JT-Shop> this mean anything /usr/include/bits/stdio2.h:203: error: declaration of C function ‘int vdprintf(int, const char*, char*)’ conflicts with
[18:25:51] <JT-Shop> ‘
[18:26:29] <JT-Shop> /usr/include/bits/stdio2.h:203: confused by earlier errors, bailing out
[18:26:44] <micges> just copy linuxcnc dev dir somewhere, do 'git reset --hard; git clean -xdf' and you'll have clean source dir
[18:26:58] <micges> without net needed
[18:27:07] <JT-Shop> ok thanks
[18:33:53] <JT-Shop> make is working properly now
[21:01:10] <skunkworks> task: main loop took 1393.616007 secondsjoint 2 following error
[21:01:33] <skunkworks> (sim - laptop went to sleep) ;)
[21:41:01] <cmorley> skunkworks: well we should thank jepler! thanks for testing panelui again.
[21:42:43] <jepler> JT-Shop: what OS version are you using, earlier when you had the error building and one of the (non-fatal) messages was emc/task/taskmodule.cc:228: warning: expected [error|warning|ignored] after ‘#pragma GCC diagnostic’
[21:44:56] <jepler> looks like that warning would occur on 10.04, and you were trying to test a bugfix for a stable version so maybe I shouldn't worry about it
[21:45:11] <jepler> .. "pragma GCC diagnostic push" is only in gcc 4.6 and newer, but 10.04 has gcc 4.04
[21:45:14] <jepler> er, 4.4
[21:45:45] <jepler> that final error is pretty weird, no clue what is going on there.
[21:46:06] <jepler> > The bug is not reproducible, so it is likely a hardware or OS problem.
[21:46:45] <jepler> maybe a hardware problem, or maybe just needs a reboot (ugh)
