#linuxcnc-devel Logs

Dec 04 2017

09:52 AM skunkworks: http://www.cnczone.com/forums/tormach-pathpilot-/350442-spurious-attempt-divide-zero-message.html
09:58 AM cradek: what a sad story
09:59 AM skunkworks: Peter FTW
10:06 AM archivist: I wonder how much it is the interpreters job to debug users code :)
10:10 AM skunkworks: yes
10:24 AM cradek: I think we already have a motion type for probing
10:29 AM seb_kuzminsky: we do
10:30 AM seb_kuzminsky: motion.motion-type is set to 5 on probe moves
10:30 AM seb_kuzminsky: also, i think dgarr already made motion abort on unexpected probe trips, e10c52ea
10:30 AM seb_kuzminsky: and we have an issue and a pr for it.
10:31 AM seb_kuzminsky: it seems like a good idea to abort motion on an unexpected probe trip
10:34 AM hazzy: seb_kuzminsky: 2.7 aborts on an unexpected probe trip, it just did not in master
10:36 AM hazzy: another JA bug :)
10:39 AM hazzy: Ah yes, dgarr's fix only aborts on probe trip during homing/jog, not in auto mode
10:41 AM seb_kuzminsky: the limit3 in master had an extra pin (.in-limit) that's not present in the old (or new) limit3 in 2.7, so the merge of the new comp to master would be a regression
10:47 AM skunkworks: Couldn't you setup a little hal logic that would switch from mdi to manual the second a motion from a jog wheel is sensed?
10:47 AM skunkworks: I was always going to do that on the K&T and never got around to it.
10:47 AM seb_kuzminsky: skunkworks: yeah, halui does something like that, but you could do it in hal too i think
10:58 AM dgarr: hazzy: i just tested 2.7.11, when running a program (AUTO mode,not MDI) a probe does *not* cause abort on the demo program used by axis.ini
10:59 AM hazzy: Yes, I know. see my message above
10:59 AM hazzy: Oh you just joined! Sorry :)
11:00 AM dgarr: so JA (2.8~pre1) behavior for probe while auto mode seems to be same as 2.7.11
11:00 AM hazzy: Yes, since your fix for #368
11:01 AM hazzy: What I should say, since you fix, 2.8~pre behaves the same as 2.7.11
11:16 AM dgarr: hazzy: above "2.7 aborts on an unexpected probe trip" --yes for mdi, no for program running (AUTO mode) that does not contain a probe move, same in 2.7.11 and 2.8~pre as far as i know
11:21 AM rene-dev: I will probably have to disable that... my probe is on the table, and might get tripped on high accelerations
11:23 AM hazzy: dgarr: sorry for the confusion, I should have been more clear. I though e10c52ea was just a fix for #368, and so made master behave the same as 2.7, but now I see e10c52ea also makes LCNC abort on any probe trip
11:25 AM skunkworks: rene-dev, same here. The probe is sensitive and trips durring shuttles..
11:25 AM hazzy: I agree with rene-dev that aborting on any probe trip should be configurable, since many (especially home shop type machines) have a probe that could easily be triped unintentionally
11:26 AM seb_kuzminsky: i can imagine a probe in a carousel tool changer might trip when it gets jostled too
11:27 AM seb_kuzminsky: too bad motion doesn't know if the probe is in the spindle or not
11:30 AM rene-dev: a probe in a toolchanger is usually turned off
11:30 AM rene-dev: eiter by ir, or a button in the taper
11:30 AM seb_kuzminsky: cradek: does your probe shut off when you unload it?
11:30 AM rene-dev: but, depending on the setup, the probe pin is high when the probe is of. renishaw probes indicate that as error
11:31 AM cradek: no, it gets the on/off signal over the IR, somehow
11:31 AM cradek: so it's never really very off
11:31 AM rene-dev: does the probe pin go high when you turn it off?
11:31 AM cradek: I don't remember
11:35 AM seb_kuzminsky: it sounds reasonable to not assume that a probe not made ready for a probe move might not be in a predictable, stable state
11:35 AM seb_kuzminsky: wow that came out confusing
11:36 AM dgarr: i'm still confused, but plan to merge the branch dgarr/285,361 once i here from pkmcnc (285) -- if you want more changes, you can do them
11:36 AM rene-dev: if there is a rising edge on any other move than a probe move, it should abort.
11:37 AM seb_kuzminsky: what i meant was: maybe we should not make assumptions about what a probe does, when it's not being actively used in a probe move
11:37 AM seb_kuzminsky: or else we should document what our assumptions about probe behavior are, so that people can configure their machines to match
11:41 AM cradek: that sounds wise to me
11:51 AM linuxcnc-build: build #412 of 1540.rip-jessie-armhf is complete: Failure [4failed compile] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1540.rip-jessie-armhf/builds/412 blamelist: John Morris <john@zultron.com>, Sebastian Kuzminsky <seb@highlab.com>
12:12 PM hiroshima5: hi, could anyone help me installing a modified version of https://github.com/LinuxCNC/linuxcnc/blob/master/src/hal/user_comps/vfdb_vfd/vfdb_vfd.c
12:12 PM hiroshima5: I've modified some of the defines to adapt it to a vfd c series
12:13 PM hiroshima5: but i can't install it using halcompile
12:13 PM hiroshima5: due to libmodbus dependencies
12:14 PM hiroshima5: halcompile --install --userspace vfdb_vfd.c gcc -Os -g -I. -I/usr/realtime-3.4-9-rtai-686-pae/include -I. -I/usr/realtime-3.4-9-rtai-686-pae/include -I/usr/include/i386-linux-gnu -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -fno-math-errno -funsafe-math-optimizations -fno-rounding-math -fno-signaling-nans -fcx-limited-range -mhard-float -DRTAI=3 -fno-fast-math -mieee-fp -fno-unsafe-math-optimizations -DRTAPI -D_GNU_SOURCE -Drealti
12:14 PM hiroshima5: .....
12:14 PM hiroshima5: -Wframe-larger-than=2560 -URTAPI -U__MODULE__ -DULAPI -Os -o vfdb_vfd /tmp/tmpnsGsUR/vfdb_vfd.c -Wl,-rpath,/lib -L/lib -llinuxcnchal /tmp/ccGJTyP4.o: In function `toggle_modbus_debug': /tmp/tmpnsGsUR/vfdb_vfd.c:249: undefined reference to `modbus_set_debug' /tmp/ccGJTyP4.o: In function `windup': /tmp/tmpnsGsUR/vfdb_vfd.c:238: undefined reference to `modbus_strerror'
12:14 PM seb_kuzminsky: hi hiroshima5
12:15 PM hiroshima5: hi kuzminsky
12:16 PM seb_kuzminsky: we normally build vfdb_vfd using gcc directly, as part of our normal build, we don't use halcompile for that one
12:16 PM seb_kuzminsky: it will probably be easiest if you duplicate what the current build system does
12:16 PM hiroshima5: could you guide me??
12:17 PM seb_kuzminsky: how extensive are the changes? does it make sense to have a whole new driver for vfdc or should it be part of the existing vfdb driver somehow?
12:17 PM hiroshima5: 4 #defines changes
12:18 PM seb_kuzminsky: is that all? tiny!
12:18 PM hiroshima5: #define SR_INV_OPSTATUS 0x2101 change to #define SR_INV_OPSTATUS 0x2119
12:18 PM hiroshima5: same for 4 more
12:18 PM seb_kuzminsky: gotcha
12:19 PM seb_kuzminsky: can you query the vfds to tell which one you're talking to? so the driver could auto-detect at startup what #defines to use?
12:19 PM hiroshima5: my idea was change it directly for that machine
12:20 PM hiroshima5: i haven't a delta vfd b
12:20 PM hiroshima5: or similar in that machine
12:20 PM seb_kuzminsky: i understand
12:20 PM hiroshima5: so i don't need it works for two differents vfds
12:21 PM hiroshima5: but yes, it would be the correct way to make it
12:21 PM hiroshima5: read those parameters from the .ini in the same way it reads some others like baud rate, parity...
12:22 PM hiroshima5: If we reach to compile it
12:22 PM seb_kuzminsky: i'm trying to make it easier for us to incorporate your changes, so that others will benefit from your work, and so that it'll be easier for us to ensure that bugfixes for vfdb are applied to vfdc, and the other way too
12:22 PM hiroshima5: I will end to program it in that way
12:22 PM seb_kuzminsky: i don't like putting the values in the ini, because it forces the user to have to know them and set the values correctly there
12:22 PM hiroshima5: but I'm not so comfortable with gcc
12:23 PM seb_kuzminsky: the ini could have a variable that says if it's vfdb or vfdc, and the driver could use that to select internal #define values that it already knows, maybe
12:23 PM hiroshima5: I think the best way it's left the parameter for a default if they are not defined in the .ini
12:23 PM hiroshima5: so the users can change it or not
12:24 PM hiroshima5: and another advantage of put them in the .ini is that more people could experiment
12:25 PM seb_kuzminsky: right, if there's no "vfdb or vfdc?" variable in the ini the driver expects vfdb, but the user can say "TYPE=vfdc" or something and the driver will use your new values to talk to a vfdc
12:25 PM hiroshima5: yes yes I get you
12:26 PM hiroshima5: could you help me with the gcc arguments to compile it
12:26 PM hiroshima5: and I make the rest
12:26 PM seb_kuzminsky: sure!
12:26 PM seb_kuzminsky: do you have the git repo checked out?
12:27 PM seb_kuzminsky: you'd edit src/hal/user_comps/vfdb_vfd/vfdb_vfd.c to add this feature, then just "make" from the src directory to recompile it
12:28 PM seb_kuzminsky: details here, feel free to ask questions if any of this doesn't make sense: http://linuxcnc.org/docs/devel/html/code/building-linuxcnc.html
12:28 PM hiroshima5: the problem is I want to install it in a machine with the package installed version
12:28 PM hiroshima5: this is why i want to compile only this component
12:29 PM hiroshima5: I know how to recompile the whole repo
12:29 PM hiroshima5: and I've made some changes many times before
12:30 PM hiroshima5: Is it possible to compile only this user component??? I suppose it's must be in the same way you can program a new user component
12:32 PM seb_kuzminsky: hiroshima5: here's what i did
12:33 PM seb_kuzminsky: i checked out the git repo, then asked the build system to compile just vfdb_vfd with verbosity turned up, by running "make V=1 ../bin/vfdb_vfd"
12:33 PM seb_kuzminsky: the output shows the full gcc command line: http://paste.debian.net/999086/
12:34 PM seb_kuzminsky: hope this helps, i'm going to step away for a bit but i'll read back later
12:34 PM hiroshima5: I think it's must be enough
12:34 PM hiroshima5: change the paths
12:34 PM hiroshima5: and it should work
12:34 PM hiroshima5: thanks
12:46 PM linuxcnc-build: build #5228 of 0000.checkin is complete: Failure [4failed] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/5228 blamelist: John Morris <john@zultron.com>, Sebastian Kuzminsky <seb@highlab.com>
02:28 PM hazzy: dgarr: Sorry if I am being thick headed, but seb_kuzminsky said "also, i think dgarr already made motion abort on unexpected probe trips, e10c52ea ", but you only made motion abort for MDI, jogging, and homing moves NOT in auto mode, correct?
02:29 PM hazzy: So now master behaves the same as 2.7.11, or am I missing something?
02:36 PM hiroshima5: seb_kuzminsky everything is ok now. vfd Delta C series working with vfdb_vfd changing the values of #define SR_INV_OPSTATUS 0x2119 #define ST_EMERGENCY_STOPPED 0x2002 #define SR_MOTOR_SPEED 0x2207 #define SR_TORQUE_RATIO 0x2208
02:37 PM hiroshima5: I use your gcc command and I copy the executable to the other machine. Now it's working
03:10 PM seb_kuzminsky: hiroshima5: cool!
03:11 PM seb_kuzminsky: if you want to make vfdc work for others, i would be happy to walk you through the process of making the change we talked about and getting it included in the next version of linuxcnc
03:11 PM seb_kuzminsky: oops, missed
04:25 PM seb_kuzminsky: hey all, don't merge 2.7 into master, it'll break
04:26 PM seb_kuzminsky: the new limit3 component in 2.7 lacks a pin that was added to the old limit3 component in master, i'm currently re-adding it in master
04:42 PM seb_kuzminsky: i added the in_limit pin to master's limit3, but the test (limit3.1) still shows a small discrepancy between the old and new limit3 component behaviors (zultron reported that this would be the case, and that he had to adjust some of the other limit3 tests to compensate)
04:42 PM seb_kuzminsky: http://paste.debian.net/999135
04:42 PM seb_kuzminsky: the columns are: "sample number", "in", "out", and "in_limit"
04:44 PM seb_kuzminsky: we can see that the old limit3 component reaches it starget a little faster, and with just a tiny bit of hunting, whereas the new one takes a handful of additional cycles to lock on, hunting a bit at the end
04:44 PM seb_kuzminsky: i think it's ok
04:44 PM seb_kuzminsky: note that the old limit3 hunted too, just much less than the new one (lines 18-22 of the paste)
04:45 PM seb_kuzminsky: so i'm planning to update the expected file for that test
04:56 PM seb_kuzminsky: I'll try
04:57 PM seb_kuzminsky: runtests is looking good so far
05:05 PM seb_kuzminsky: hmm, i pushed and github notified the buildbot, but it did not notify here in irc
05:06 PM seb_kuzminsky: anyway, all clear, master's got zultron's new limit3 comp and the .in-limit pin and the affected test has been updated
07:02 PM skunkworks: Thanks seb!
07:48 PM jepler: yes, thank you seb_kuzminsky
07:49 PM * seb_kuzminsky takes a bow
07:49 PM seb_kuzminsky: but really, credit should go to zultron, who fixed all the bugs
10:05 PM -!- #linuxcnc-devel mode set to +v by ChanServ