#linuxcnc-devel Logs

May 30 2018

05:06 AM narogon: seb_kuzminsky i'm suffering https://github.com/LinuxCNC/linuxcnc/issues/298
05:08 AM narogon: the issue is closed but It doesn't work for me
05:08 AM narogon: I change PYTHON_GST=python-gst-1.0,gstreamer1.0-plugins-base from debian configure and create the deb package
05:09 AM narogon: but import gst that there is in gmoccapy files doesn't work
05:09 AM narogon: i'm using #1 SMP PREEMPT RT Debian 4.9.65-3+deb9u2 (2018-01-04)
05:24 AM rmu: jepler: removing ubuntu-minimal didn't do any damage here on my work-pc, the safer bet is to just remove the motd-file if it bugs you ;), ubuntu-minimal will probably be needed for system upgrades
05:31 AM narogon: i get gmoccapy to work
05:31 AM narogon: but installing jessie packages from https://debian.pkgs.org/8/debian-main-amd64/libgstreamer0.10-0_0.10.36-1.5_amd64.deb.html
05:31 AM narogon: It must be solved in any way
08:42 AM jepler: pkgs.org is not operated by the debian project and when you retrieve packages from there you don't get the normal checks that prove the package is the specific one that was built and signed by the debian organization. Anyway, the results of combining packages from an old debian distro and a new debian distro are not guaranteed by anybody. better to figure out exactly how the gst authors have
08:42 AM jepler: moved the cheese, and fix the code in linuxcnc to follow that moving target.
08:43 AM jepler: gmoccapy author can comment further on the status of the fix, whether it is in 2.7 or just master, etc
08:46 AM jepler: (pkgs.org simply links to a debian http mirror for the actual file contents, which is better than hosting the .deb themselves; but it still means you don't get apt's integrity checks when you download and install with dpkg)
10:17 AM jepler: here we go with a minor joomla update... should not interrupt the forum's availability, but you never know
11:00 AM seb_kuzminsky: naragon: what distro are you on? what version of linuxcnc?
11:01 AM seb_kuzminsky: oh they left
11:03 AM seb_kuzminsky: in general, the preferred way to notify us of bugs that need fixing is to open an issue on github
05:43 PM andypugh: In Master do rapid moves get limited to joint max velocities in non-trivial kins?
06:38 PM seb_kuzminsky: i believe the answer is "no", but i'm not 100% certain
07:24 PM andypugh_ is now known as andypugh
07:37 PM rene-dev_: andypugh joint acc and vel limits are always ignored in world mode
07:38 PM andypugh: That seems non-ideal
07:38 PM rene-dev_: thats by design
07:38 PM andypugh: The background is https://forum.linuxcnc.org/10-advanced-configuration/34609-does-linuxcnc-have-joint-interpolation-inside#111105
07:38 PM rene-dev_: thats because the planer has no idea what a kinematic is
07:39 PM andypugh: (Someone wants joint-space point-to-point moves)
07:41 PM rene-dev_: https://github.com/LinuxCNC/linuxcnc/issues/97
07:41 PM andypugh: It seems like “something” could compare the joint positions now and the joint positons last servo period and tweak the velocity to suit? (adaptive feed is able to do this, after all)
07:41 PM rene-dev_: no, no
07:42 PM rene-dev_: thats a hack. its the planners job to do that.
07:43 PM andypugh: OK, the planner could call the kins at t and t+dt and calculate joint velocity.
07:43 PM rene-dev_: it cant with the current design ;D
07:44 PM rene-dev_: because kins runs in hal
07:46 PM rene-dev_: what he is saying, is correct, linuxcnc will fail with joint following error if you try that. because it doesnt check the joint limits.
07:46 PM rene-dev_: and no, Im not aware of a way of controlling joints form gcode...
07:50 PM andypugh: kins is loaded by HAL, but isn’t part of HAL. It exports a fwd and rev calculation function that _anything_ can then call.
07:50 PM andypugh: (Including, I think, any other software on the machine, but I am fuzzy there)
07:52 PM andypugh: (EXPORT_SYMBOL)
07:53 PM rene-dev_: ah, yes. ok... but still, it needs some work in the planner
07:54 PM rene-dev_: when the planner works out the speed, by looking at what the slowest axis is, it also needs to look at the joints.
07:55 PM rene-dev_: it really only affects non kartesian kinematic users...
07:56 PM andypugh: Yes. My point is that it is possible to use the kins functions like a numerical differentiation to get a velocity kins and (potentially) an acceleration kins.
07:57 PM andypugh: (Being maths and not data, you don’t have the noise problems that you would have double-differentiating measurments)
08:00 PM rene-dev_: yes, but the number of solutions can be 0, 1, 2, or infinity.
08:01 PM rene-dev_: or, any other number...
08:05 PM rene-dev_: joint -> axis is always one solution, but not the other way around.
08:05 PM andypugh: But at any one time the inverse kins is only doing one thing.
08:06 PM rene-dev_: yes, but you need to keep track what its doing
08:06 PM andypugh: (we don’t see the elbows oscillating randomly between solutions during a straight cartesian move)
08:09 PM rene-dev_: yes, because a 6 axis robot is constrained on most moves. and the scara kins for example only ever allows the elbow to go in one direction
08:10 PM rene-dev_: on 6 axis robots you get in trouble when lining up 2 of the rotational axis.
08:10 PM andypugh: I confess I am discussing from a position of ignorance. I don’t even really understand the difference between tp and tc
08:14 PM rene-dev_: one thing decides where you are going, like the satnav in your car
08:15 PM rene-dev_: the other thing decides how you get there, without violating any limits, like your feet pressing the brake and accelerator pedals
08:16 PM rene-dev_: ignore the steering wheel in this example, thats controlled by the satnav...