Re: [Emc-developers] Found a new constraint violation...
ok - as you can see from my screen shot I was actually running 2.6.3 So - I actaully ran master and - it runs as expected... One of the many small bugs fixed.. Yay Rob!! http://electronicsam.com/images/KandT/testing/Screenshot%20from%202014-10-20%2015:02:29.png sam On 10/20/2014 02:37 PM, sam sokolik wrote: > Playing around with dxf2gcode.. (cool program btw..) It generated this > file (running in master) > > http://electronicsam.com/images/KandT/testing/SPACOUT1.ngc > > it violates the negative y acceleration on line 18,23,37 and so on. > > http://electronicsam.com/images/KandT/testing/Screenshot%20from%202014-10-20%2014:21:17.png > > > it seems to be switching to parabolic blending maybe at that point? (you > can see the strait g64 tolerance is doing what I have seen in parabolic > blending.. > > actually really not quite sure what it is doing.. > > sam > > -- > Comprehensive Server Monitoring with Site24x7. > Monitor 10 servers for $9/Month. > Get alerted through email, SMS, voice calls or mobile push notifications. > Take corrective actions from your mobile device. > http://p.sf.net/sfu/Zoho > ___ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] incremental change to linuxcnc's APIs for user interfaces
> From: viesturs.la...@gmail.com > Date: Mon, 20 Oct 2014 20:48:42 +0300 > To: emc-developers@lists.sourceforge.net > Subject: Re: [Emc-developers] incremental change to linuxcnc's APIs for user > interfaces > > 2014-10-19 16:06 GMT+03:00 Jeff Epler : > > Last night at the Texas fest, Chris Radek, Seb Kuzminsky, and I > > brainstormed an outline of an incremental way forward, which will take > > at least two releases before the ultimate goal of transitioning from NML > > to a different IPC method. > > Is it just me who feels that this basically is reinventing the wheel? > Because getting rid of NML is already done in Machinekit. > > Viesturs > Not just you. userspace realtime too. -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] Found a new constraint violation...
Playing around with dxf2gcode.. (cool program btw..) It generated this file (running in master) http://electronicsam.com/images/KandT/testing/SPACOUT1.ngc it violates the negative y acceleration on line 18,23,37 and so on. http://electronicsam.com/images/KandT/testing/Screenshot%20from%202014-10-20%2014:21:17.png it seems to be switching to parabolic blending maybe at that point? (you can see the strait g64 tolerance is doing what I have seen in parabolic blending.. actually really not quite sure what it is doing.. sam -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] incremental change to linuxcnc's APIs for user interfaces
2014-10-19 16:06 GMT+03:00 Jeff Epler : > Last night at the Texas fest, Chris Radek, Seb Kuzminsky, and I > brainstormed an outline of an incremental way forward, which will take > at least two releases before the ultimate goal of transitioning from NML > to a different IPC method. Is it just me who feels that this basically is reinventing the wheel? Because getting rid of NML is already done in Machinekit. Viesturs -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] linuxcnc multiple UI Re: Emc-developers Digest, Vol 102, Issue 12
On Oct 20 2014 3:37 AM, bruno wrote: > it seems the poster want to create a new API to solve a problem which > is > already solved but needs a bit of work: > > - improve NML documentation > - fix the NML library used by emcrsh, emclcd, etc. and their clients > to > use a different configuration for each NML client > > NML seems very capable, might as well use it and fix the clients > instead > of creating a new architecture and associated bugs that will come > with it. > just my 2 cents worth... Fundamentally the problem is that no one is really maintaining NML, and if I am not mistaken that has been the case for something like a decade. On the other hand, if you were to volunteer ;-) In all seriousness, NML was developed in the early 90's IIRC, and is in sad need of a bit of maintenance (and not just the docs). If you or someone wanted to take over the task, there should be a list of things that people need/want it to do that it either does not do, or barely does. On the other hand, going with a more standard interface (like the ones suggested before), or something that is inherently designed for distributed operation with multiple UI's, then it would likely be more maintainable in the long run. EBo -- -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] incremental change to linuxcnc's APIs for user interfaces
On Mon, Oct 20, 2014 at 07:53:24PM +1100, Frank Tkalcevic wrote:
> I run axis on the local machine, then remote to it using keystick.
It also *typically* works when using e.g., axis + halui or axis +
linuxcncrsh.
However, sometimes it doesn't. This leads to reports like 328 (axis +
halui, using halui sometimes axis is unresponsive for a few seconds)
and 395 (axis + linuxcncrsh, linuxcncrsh becomes totally unresponsive)
The problem crops up when the UI wants to do one of two things: wait to
be certain its command was received by task; or wait to be certain its
command was fully acted on by task.
All the current UIs have an implementation similar to this one (from shcom):
int emcCommandWaitReceived(int serial_number)
{
double end = 0.0;
while (emcTimeout <= 0.0 || end < emcTimeout) {
updateStatus();
if (emcStatus->echo_serial_number == serial_number) {
return 0;
}
esleep(EMC_COMMAND_DELAY);
end += EMC_COMMAND_DELAY;
}
return -1;
}
In this implementation, the UI waits for up to emcTimeout seconds (or forever,
if emcTimeout <= 0) for the stat buffer to hold a certain serial number in
echo_serial_number. (problems also arise in emcCommandWaitDone, which in
shcom calls out to emcCommandWaitReceived as a first step)
Here's one sequence of operations which causes this algorithm to go wrong:
UI 1UI 2Task
send SN 1
receive SN 1
echo SN 1
send SN 1001
receive SN 1001
echo SN 1001
poll status buffer
until echo SN = 1
(never finishes)
.. and this sort of situation is easy to trigger. In bug 395, it is
easy to trigger because when linuxcncrsh is waiting for "SET MODE
MANUAL", AXIS automatically sends another command when it reads the
stat buffer and sees the mode has changed to manual. (UI 1 =
linuxcncrsh, UI 2 = axis)
I am aware that there must be some differences in behavior when using
the different client-name arguments to RCS_CMD_BUFFER / RCS_STAT_CHANNEL
etc but it doesn't seem to affect the way echo_serial_number behaves.
To confirm this belief I had, I ran keystick (uses client name string
"keystick" as you point out) and linuxcnctop (uses client name string
"xemc", I assume). As I issued commands in linuxcnctop, I saw changing
echo_serial_number values in linuxcnctop.
This is why I said in my original message "the serial number method ...
simply does not work". In my analysis, this bad behavior of multiple
UIs in no way is a bug in libnml. It's a bug in the way "wait for
command to be received / completed" were implemented on top of NML.
The combo keystick + axis probably works better than many because
keystick and axis both have finite timeouts, while linuxcncrsh
apparently defaults to an infinite timeout so it readily exhibits very
bad behavior when it triggers this bug.
I'm sure open to solving this bug properly while retaining NML as the
IPC method of LinuxCNC, because even if *this* project gets done on the
fastest likely schedule (new API in 2.8, new backend in 2.9), *and* we
try to adopt twice-a-year releases, it's still ~18 months to 2.9 and a
fix for this class of bug.
Perhaps it is worth returning to the solution suggested in bug 328, and
ignoring the derail that happened right away (amusingly enough, by
somebody else who wanted to replace NML). That patch uses an NML queue,
which makes message reception reliable; and implements a globally
increasing serial number. This makes it possible to wait for
echo_serial_number >= serial_number (instead of ==), so it's OK if
another UI sends a command around the same time you do.
(however, this means you can't reliably determine whether your command
was successful [RCS_DONE] or failure [RCS_ERROR] because you're likely
to see the status of some command issued subsequent to your own. but
mostly UIs don't actually indicate this success/failure result, but
instead rely on an operator message being shown when there's an error.)
Jeff
--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] linuxcnc multiple UI Re: Emc-developers Digest, Vol 102, Issue 12
On 20 October 2014 10:37, bruno wrote: > NML seems very capable, might as well use it and fix the clients instead > of creating a new architecture and associated bugs that will come with it. As far as I know the Machinekit project is also trying to get rid of NML (and might already have done so). I seem to recall that the chap at NIST who wrote NML and built EMC round it is also of the opinion that it is no longer a sensible thing to be using. -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] linuxcnc multiple UI Re: Emc-developers Digest, Vol 102, Issue 12
it seems the poster want to create a new API to solve a problem which is already solved but needs a bit of work: - improve NML documentation - fix the NML library used by emcrsh, emclcd, etc. and their clients to use a different configuration for each NML client NML seems very capable, might as well use it and fix the clients instead of creating a new architecture and associated bugs that will come with it. just my 2 cents worth... Bruno On 10/20/14 11:22 AM, bruno wrote: > On 10/20/14 11:00 AM, emc-developers-requ...@lists.sourceforge.net wrote: >> -- >> >> Message: 7 >> Date: Mon, 20 Oct 2014 19:53:24 +1100 >> From: "Frank Tkalcevic" >> Subject: Re: [Emc-developers] incremental change to linuxcnc's APIs >> foruserinterfaces >> To: "'EMC developers'" >> Message-ID:<003601cfec43$51445370$f3ccfa50$@franksworkshop.com.au> >> Content-Type: text/plain;charset="us-ascii" >> >>> >(The summary of those bugs is: the serial number method for UIs to >>> ensure >> a >>> >message is acted upon by task simply does not work when there is >>> not just >>> >one UI. No simple modification will make it work, and no one in the >> project >>> >in 10+ years has taken the time to understand NML with the depth >>> necessary >>> >to suggest a correct approach.) >> 1. Copy linuxcnc.nml to your run directory. >> 2. Edit linuxcnc.nml and create another configuration section for >> your UI >> 3. Edit your .ini file and add the NML_FILE configuration >> 4. When your UI connects to NML, use the name of the new nml section. >> >> I run axis on the local machine, then remote to it using keystick. >> >> Keystick still works because it makes its own NML connection >> "keystick" ... >> >> src/emc/usr_intf/keystick.cc >> >> emcStatusBuffer = new RCS_STAT_CHANNEL(emcFormat, "emcStatus", >> "keystick", >> emc_nmlfile); >> >> >> linuxcncrsh doesn't work because it uses a common library (that >> other UIs >> use) to connect to NML. It uses the same configuration, "xemc". >> >> src/emc/usr_intf/shcom.cc >> >> emcStatusBuffer = >> new RCS_STAT_CHANNEL(emcFormat, "emcStatus", "xemc", >> emc_nmlfile); >> >> Everything that uses this library can't run simultaneously - emcsh, >> emcrsh, >> emclcd, axis - axis hard codes the xemc configuration in >> src/emc/usr_intf/axis/extensions/emcmodule.cc - so axis, and anything >> that >> uses the emcmodule python library fail. >> >> RCS_STAT_CHANNEL *c = >> new RCS_STAT_CHANNEL(emcFormat, "emcStatus", "xemc", file); >> >> >> So, you can have multiple UIs. >> >> However, if an upgraded API allows for other new functionality, I'm >> all for >> it. >> > > -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] incremental change to linuxcnc's APIs for user interfaces
> (The summary of those bugs is: the serial number method for UIs to ensure a > message is acted upon by task simply does not work when there is not just > one UI. No simple modification will make it work, and no one in the project > in 10+ years has taken the time to understand NML with the depth necessary > to suggest a correct approach.) 1. Copy linuxcnc.nml to your run directory. 2. Edit linuxcnc.nml and create another configuration section for your UI 3. Edit your .ini file and add the NML_FILE configuration 4. When your UI connects to NML, use the name of the new nml section. I run axis on the local machine, then remote to it using keystick. Keystick still works because it makes its own NML connection "keystick" ... src/emc/usr_intf/keystick.cc emcStatusBuffer = new RCS_STAT_CHANNEL(emcFormat, "emcStatus", "keystick", emc_nmlfile); linuxcncrsh doesn't work because it uses a common library (that other UIs use) to connect to NML. It uses the same configuration, "xemc". src/emc/usr_intf/shcom.cc emcStatusBuffer = new RCS_STAT_CHANNEL(emcFormat, "emcStatus", "xemc", emc_nmlfile); Everything that uses this library can't run simultaneously - emcsh, emcrsh, emclcd, axis - axis hard codes the xemc configuration in src/emc/usr_intf/axis/extensions/emcmodule.cc - so axis, and anything that uses the emcmodule python library fail. RCS_STAT_CHANNEL *c = new RCS_STAT_CHANNEL(emcFormat, "emcStatus", "xemc", file); So, you can have multiple UIs. However, if an upgraded API allows for other new functionality, I'm all for it. -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
