[Emc-developers] Ran into a intermittent problem with Jog stop.
I'm using master that I down loaded about 10 days ago with Gmoccapy that came with it. I was controlling my mill just using the jog buttons and chose not to send commands using MDI mode. This machining work required the jog button to be pushed for minutes at a time and then released when the desired axis travel was completed. On a number of occasions I had to push the machines emergency stop button to stop the jog since releasing the jog button did absolutely nothing. Most of my movements were slow less that 3 inches per minute in the X axis with a travel range of about 11 inches so this took a considerable amount of time. Most of the time jog stopped as expected but not all the time and came close to breaking to installed cutting tool. I'm thinking that this may be related to status not seeing that jog button was released or that status for that particular button froze in some way, perhaps even by some sort of time out. I failed to see if the button in Gmoccapy changed color from yellow to white or not when the button was released. I think the code used for manual jogging and its related status info may need a review to see if there is something being overlooked that could be time related. I do not have any time to look into this further now but this occurred perhaps 8 times in the last several days using this particular manual jogging machining method. ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] A vision for working now to LinuxCnc version 10
I had made some changes in my note file names to add .txt file extension. Its liklye best the use the main link to navigate to my notes and other info when posted. https://github.com/auto-mation-assist/LinuxCnc-OpenDDS-Work After running the 6 tests it completed so far makes me confident enough that OpenDDS is installed and able to function. I will be working on trying to get it linked into my LinuxCnc master clone and Initially to the tasks related to the IO control for some of the simple on/off commands and their status replies. Not at all sure on how to do that yet. Will need to do more research on how to integrate it into a application. On 12/18/2022 5:23 PM, Bari wrote: On 12/18/22 18:24, Johannes Fassotte wrote: I had a chance to do some work on OpenDDS while waiting for parts for another project. I installed OpenDDS with its depends on my Linux Mint 20 development computer and made some notes on how I installed it and all the depends. I have not checked out the built in tests yet described in the OpenDDS Developers Guide which need to run under Perl. I have put my current install "first.dds.install" note on github. https://github.com/auto-mation-assist/LinuxCnc-OpenDDS-Work/install-notes/first.dds.install Main folder at: https://github.com/auto-mation-assist/LinuxCnc-OpenDDS-Work I did not note how long configure ran, but "make" took about 2 hours, sudo "make install" about 2 minutes. Hope the info there will be helpful and will add to these as the project continues. Johannes, Thank you for kicking this off. Looks like a typo in your first link. This works for me: https://github.com/auto-mation-assist/LinuxCnc-OpenDDS-Work/blob/main/install-notes/first.dds.install ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] A vision for working now to LinuxCnc version 10
I had a chance to do some work on OpenDDS while waiting for parts for another project. I installed OpenDDS with its depends on my Linux Mint 20 development computer and made some notes on how I installed it and all the depends. I have not checked out the built in tests yet described in the OpenDDS Developers Guide which need to run under Perl. I have put my current install "first.dds.install" note on github. https://github.com/auto-mation-assist/LinuxCnc-OpenDDS-Work/install-notes/first.dds.install Main folder at: https://github.com/auto-mation-assist/LinuxCnc-OpenDDS-Work I did not note how long configure ran, but "make" took about 2 hours, sudo "make install" about 2 minutes. Hope the info there will be helpful and will add to these as the project continues. On 12/6/2022 10:55 AM, Bari wrote: On 12/5/22 15:21, Johannes P Fassotte wrote: On 12/5/2022 6:10 AM, Bari wrote: A pdf that explains where DDS fits in to industry https://www.dds-foundation.org/sites/default/files/RTILunchAddressOMG2014v2.pdf If we use DDS it might make LCNC compatible with the industry of the future. Is everyone jumping onto the DDS bandwagon? Which messaging system will gives us the best chance at fitting into factory automation, CNC machines and robotics of the near future (next 20 years)? Will this best solve the issues of separating the controls from the GUI over the network as well as connect LCNC to factory controls and robot material handlers? Is this mission creep or killing two birds with one stone? Bari, I tend to agree that this is a good solution. In looking at the openDDS project I see that the project has been forked 408 times on github including my own fork. It also has a good developers guide that contains some 249 pages of information and also has the required support package for TOA available which has development guide that has some 1262 pages. OpenDDS seems like it has good documentation on its own and thus only requires LinuxCnc documentation to be added on how to get it to install and get it working with LinuxCnc. I think that working on this is much more beneficial to LinuxCnc than my previous concept which obviously does not have a lot of support so I may as well forget about working on that. But that does not mean that the requirement for improved network capability does not exist. OpenDDS has its own own development team which thus requires less support from the LinuxCnc development team. All that needs to be done is to get it working within LinuxCnc. So my intention is to work on helping to accomplishing that. OpenDDS uses CorBa instead of Redis so Redis will most likely not be required. My starting point for this project is to get openDDS working inside and in parrallel with current LinuxCnc master code, without changing LinuxCnc code and to only add the code required to make openDDS functional within LinuxCnc. Once it is functioning and able to run simple self tests then start working on routing individual LinuxCnc commands along with the status data of those into openDDS and route those to an prior developed Labview based UI running on a Windows10 computer. That will be helpful with checking the networking functions and any debugging work. Labview has some tools that are very handy for doing that but others joining the project could decide use any UI that has remote ability for there own testing. This seems like an excellent project to undertake and I'm somewhat excited about getting started on this project. OpenDDS appears to have good support and is already being used for such purposes. I have downloaded what I believe to be all required items for installation and will get my Debian development system set up to start doing work on this before the end of the year. Sounds great. Let us know when you have a public repo so that we can follow your deep dive into this. ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] A vision for working now to LinuxCnc version 10
DDS looks very interesting and I will plan to look into it more today. Thanks for the link to DDS. Future compatibility with other industrial work is very important and highly desirable. Johannes - Fairbanks, AK 99712 > On Dec 5, 2022, at 6:13 AM, Bari wrote: > > A pdf that explains where DDS fits in to industry > https://www.dds-foundation.org/sites/default/files/RTILunchAddressOMG2014v2.pdf > > If we use DDS it might make LCNC compatible with the industry of the future. > Is everyone jumping onto the DDS bandwagon? Which messaging system will gives > us the best chance at fitting into factory automation, CNC machines and > robotics of the near future (next 20 years)? Will this best solve the issues > of separating the controls from the GUI over the network as well as connect > LCNC to factory controls and robot material handlers? Is this mission creep > or killing two birds with one stone? > > > > ___ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] A vision for working now to LinuxCnc version 10
I’m fairly familiar with machine kit and it has nothing to do with that. It has strictly to do with modernizing the built in remote interface that Linuxcnc was born with.. I think that this will get done individuals like me that get together and see the advantages that this offers. I usually get referred to machinekit liked you did which is really like saying go away, we don’t want to hear this because it is not compatible with existing plans and therefore rejected. Using this method can allow any Ui including your efforts to function with minimum changes and with mostly the addition of a built in secure TCP interface. It would be nice if you could help with development of the Python version of the proposed interface. Johannes - Fairbanks, AK 99712 > On Dec 3, 2022, at 10:58 AM, Chris Morley wrote: > > Have you looked at machinekit code? Is that similar to what you want? > > Chris > > > > Sent from my Galaxy > > > > Original message > From: Johannes P Fassotte > Date: 2022-12-03 11:48 a.m. (GMT-08:00) > To: emc-developers@lists.sourceforge.net > Subject: [Emc-developers] A vision for working now to LinuxCnc version 10 > > In order to help clarify what I would like to see in not only version 10 > of LinuxCnc but also in the current version 9 future work. I will start > working on this as soon as my new circuits board for my metal detectors > are populated with all the SMD components. The circuit blank circuit > boards arrived yesterday. This requires placing 235 SMD componets on > each of the boards and likely take about seven days. > > My goal for LinuxCnc is to provide a way for any user to interface any > UI to LinuxCnc with a secure TCP network connection. LinuxCnc has had > such an interface from its inception via the NML network servers however > these are absolutely insecure and anyone with a bit of knowledge of > remote NML commands can take control of LinuxCnc if those network ports > are left open. Thus LinuxCnc needs modern secure network interfaces to > replace the ones that were designed in from the very start government > development and just ignored. Not many use this interface because it > does not provide complete information due to developers add-ons such as > Python that seem to just live in their own world within LinuxCnc and do > not provide any info into the NML network links. NML is likely the > hardest thing to deal with and very difficult to replace but in general > works just fine. > > About 12 years ago I developed code to allow remote control of a lot of > time sensitive industrial and electronic equipment that was over 500 > miles from the actual normal user interface. The equipment being > remotely controlled was located in a isolated area and without > communication links and thus those also had to be designed and > implemented. The overall bandwidth of the communication link was divided > into remote receive data, multiple command channels, status and error > channels. The system was designed for very high reliability and met all > design goals and is still in operation with some equipment updates > having been made. > > The goal of me mentioning this is that I know that having a distributed > data system with equipment to be controlled in one location and the user > interface in an other more convenient location doe not have to suffer > from reliability issues when properly executed. What it does provide is > flexibility. In case of LinuxCnc which runs on Linux user interfaces and > there support requirements can be offloaded from the Linux system and > run on Windows based system instead or even on another Linux Based > computer. Which as I mentioned before reduces the need to load up the > machine control computer with support code that is not directly related > to its main function which if of course to control a machine and output > status info back to the user and process commands from the UI that may > be located some distance away and not in a noisy environment. There are > of coarse other ways to snoop into a Machine controller and some have > implemented one or more o those methods strictly because LinuxCnc does > not have a proper way of handing remote UI's. > > I thing that even version 9 master has a good deal of the required code > to fix that problem by just adding some code to do some data routing and > adding some secure TCP channels. I have drawn a basic block diagram of > what would be required and attached it. > > > > ___ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] Question on status for joints (16) ?
I'm testing with the axis UI with master to see how I can pull status
data out in a format that is suitable for use with my Labview UI code,
and used the below code for one of my tests to see how the data is
formatted.
c = linuxcnc.command()
e = linuxcnc.error_channel()
s = linuxcnc.stat()
s.poll() # get current values
for x in dir(s):
if not x.startswith("_"):
print (x, getattr(s,x))
The data I get back looks good except I have a question as to why there
are 16 joints (jointType) under the 'joint' heading reported.
I aligned the data in the list supplied below to make it easy to read
and noticed that Y axis is not giving its data correctly. I'm not used
to using the axis UI so that may be causing that particular problem.
In the below partial listing why are there 16 jointType's reported. does
that not exceed the number of joints that Linuxcnc can handle?
-
ini_filename /home/cnc/linuxcnc/configs/cnc1/cnc1.ini
inpos True
input_timeout False
interp_state 1
interpreter_errcode 0
joint (
{'jointType': 1, 'units': 0.03937007874015748, 'backlash': 0.001,
'min_position_limit': -50.0,
'max_position_limit': 50.0, 'max_ferror': 5.0, 'min_ferror': 5.0,
'ferror_current': 0.0,
'ferror_highmark': 0.15607306025994486, 'output':
-0.15607306025994486, 'input': -0.15607306025994486,
'velocity': 0.0, 'inpos': 1, 'homing': 0, 'homed': 0, 'fault': 0,
'enabled': 0, 'min_soft_limit': 0,
'max_soft_limit': 0, 'min_hard_limit': 0, 'max_hard_limit': 0,
'override_limits': 0},
{'jointType': 1, 'units': 0.03937007874015748, 'backlash': 0.001,
'min_position_limit': -50.0,
'max_position_limit': 50.0, 'max_ferror': 5.0, 'min_ferror': 5.0,
'ferror_current': 0.0,
'ferror_highmark': 0.0, 'output': -0.0, 'input': -0.0,
'velocity': 0.0, 'inpos': 1, 'homing': 0,'homed': 0, 'fault': 0,
'enabled': 0, 'min_soft_limit': 0,
'max_soft_limit': 0, 'min_hard_limit': 0, 'max_hard_limit': 0,
'override_limits': 0},
{'jointType': 1, 'units': 0.03937007874015748, 'backlash': 0.0035,
'min_position_limit': -50.0,
'max_position_limit': 50.0, 'max_ferror': 5.0, 'min_ferror': 5.0,
'ferror_current': 0.0,
'ferror_highmark': 0.642992024419062, 'output': -0.642992024419062,
'input': -0.642992024419062,
'velocity': 0.0, 'inpos': 1, 'homing': 0, 'homed': 0, 'fault': 0,
'enabled': 0, 'min_soft_limit': 0,
'max_soft_limit': 0, 'min_hard_limit': 0, 'max_hard_limit': 0,
'override_limits': 0},
{'jointType': 2, 'units': 1.0, 'backlash': 0.001,
'min_position_limit': -50.0,
'max_position_limit': 50.0, 'max_ferror': 5.0, 'min_ferror': 5.0,
'ferror_current': 0.0,
'ferror_highmark': 0.0, 'output': 0.0, 'input': 0.0,
'velocity': 0.0, 'inpos': 1, 'homing': 0, 'homed': 0, 'fault': 0,
'enabled': 0, 'min_soft_limit': 0,
'max_soft_limit': 0, 'min_hard_limit': 0, 'max_hard_limit': 0,
'override_limits': 0},
{'jointType': 1, 'units': 1.0, 'backlash': 0.0, 'min_position_limit':
-1.0,
'max_position_limit': 1.0, 'max_ferror': 1.0, 'min_ferror': 1.0,
'ferror_current': 0.0,
'ferror_highmark': 0.0, 'output': 0.0, 'input': 0.0,
'velocity': 0.0, 'inpos': 1, 'homing': 0, 'homed': 0, 'fault': 0,
'enabled': 0, 'min_soft_limit': 0,
'max_soft_limit': 0, 'min_hard_limit': 0, 'max_hard_limit': 0,
'override_limits': 0},
{'jointType': 1, 'units': 1.0, 'backlash': 0.0, 'min_position_limit':
-1.0,
'max_position_limit': 1.0, 'max_ferror': 1.0, 'min_ferror': 1.0,
'ferror_current': 0.0,
'ferror_highmark': 0.0, 'output': 0.0, 'input': 0.0,
'velocity': 0.0, 'inpos': 1, 'homing': 0, 'homed': 0, 'fault': 0,
'enabled': 0, 'min_soft_limit': 0,
'max_soft_limit': 0, 'min_hard_limit': 0, 'max_hard_limit': 0,
'override_limits': 0},
{'jointType': 1, 'units': 1.0, 'backlash': 0.0, 'min_position_limit':
-1.0,
'max_position_limit': 1.0, 'max_ferror': 1.0, 'min_ferror': 1.0,
'ferror_current': 0.0,
'ferror_highmark': 0.0, 'output': 0.0, 'input': 0.0,
'velocity': 0.0, 'inpos': 1, 'homing': 0, 'homed': 0, 'fault': 0,
'enabled': 0, 'min_soft_limit': 0,
'max_soft_limit': 0, 'min_hard_limit': 0, 'max_hard_limit': 0,
'override_limits': 0},
{'jointType': 1, 'units': 1.0, 'backlash': 0.0, 'min_position_limit':
-1.0,
'max_position_limit': 1.0, 'max_ferror': 1.0, 'min_ferror': 1.0,
'ferror_current': 0.0,
'ferror_highmark': 0.0, 'output': 0.0, 'input': 0.0,
'velocity': 0.0, 'inpos': 1, 'homing': 0, 'homed': 0, 'fault': 0,
'enabled': 0, 'min_soft_limit': 0,
'max_soft_limit': 0, 'min_hard_limit': 0, 'max_hard_limit': 0,
'override_limits': 0},
{'jointType': 1, 'units': 1.0, 'backlash': 0.0, 'min_position_limit':
-1.0,
'max_position_limit': 1.0, 'max_ferror': 1.0, 'min_ferror': 1.0,
'ferror_current': 0.0,
'ferror_highmark': 0.0, 'output': 0.0, 'input': 0.0,
'velocity': 0.0, 'inpos': 1, 'homing': 0, 'homed': 0, 'fault': 0,
'enabled': 0, 'min_soft_limit': 0,
[Emc-developers] Using `main` instead of `master` branch
I really wish that everyone would concentrate on improving the software instead of worrying about the name of the version that most consider as being the master. It is master since it is where the code is actually shared with everyone. It is not beneficial to anyone to have a narrow view for the word master. There is absolutely no reason to change it to anything. The developers are actually the masters since they hold the various development versions that get merged into what is know as the "master" used for distribution. ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] EMC Master NML configuration file buffer size changes
Gene , I use my labview based network interfaces for all my remote work into linuxcnc. I put most of my info in the regular forum at: https://forum.linuxcnc.org/41-guis/36920-labview-ui-project-for-linuxcnc I'm not familiar with the tool you are using so can't comment on that but I'm sure that it cannot encode NML commands to request status data. To test for this you must send a properly formatted NML peek status request to linuxCNC from a remote to the status buffer using the proper port. If you don't do that then you will not see anything since no data transfer has been requested. The commands sent must also update its serial number with each command or the linuxCNC TCP server will shut down due to errors or buffer overflows. This will also occur if the wrong number of bytes are sent since that would cause confusion on the linuxCNC end and will cause delays in any response back and sooner or later a server shutdown which will require a linuxCNC restart. There has to be a good sequence of status request commands sent before being able to see the pattern for the bad intermixed data I described. Thus you have to send your properly encoded NML status request commands and then pull the data out of the linuxCNC buffer rapidly since these are send to you in very rapid succession. Using wrong byte values for messages sent by linuxcnc to the remote will cause serious trouble shooting problems. Every thing must be correct. One of the problems with the unknown data is that number of bytes is not constant and I suspect that they may be arrays in real time that contain nothing but NML encoded zeros. If this data is not displayed in hex those zeros will likely not be seen. These zeros likely represent an initialized array with no data written into it and only sized. I'm not sure at all if real time is really needed for anything related to tool table data since changing a tool is turtle slow to start with. If there is little bit of data that real time needs from a tool it should be able to be routed to real time without affecting the normal NML buffers. Tool table data should be able to be requested by using transfer methods like that in place for emcStatus request commands from a remote, which I have described in the past, but not from the normal emcStatus buffer. Request for tool status can easily be routed to a different buffer by the remote to access a buffer dedicated to tool status data only. Does real time really need to know everything about a 1000 tools at once, or is just one at a time enough to satisfy it? What values for each tool does real time actually actually use for machining and not for moving tools around? I Hope this helps. On 11/4/2020 9:31 PM, Gene Heskett wrote: On Wednesday 04 November 2020 23:33:51 Johannes Fassotte wrote: I wanted to post a update on this since I have isolated the source of unknown data being intermixed with my status requests data sent via the tcp buffer to my remote. This unknown and not requested data completely disrupts the normal flow of status data at 6 times in a row and this sequence repeats at itself at regular intervals. Please describe how you are observing this, Johannes. I perhaps am not doing it right, but logged into any of my machines with ssh -Y, I am not observing anything unusual in the status reports I can pull up while running linuxcnc -l so as to see that machine on my screen here in the house. I have back tracked this problem to 7 April 2020 and commit b51ef8c to "increase max tools from 55 to 1000" and that this has caused a problem from that point forward up to and including the current master. It is also the cause of the very large increase and what I think is an unreasonable increase in NML buffer sizes. I had not done much development work this summer and thus this issue was not noticed until a recent update. It seems to me that a regular file or small database is more than sufficient for a tool table with a choice depending on if pictures are wanted or not. I see absolutely no valid reason for messing around with NML buffer sizes to handle the tool table. I think that the best thing to do is to develop a more suitable way to handle the tool table and backing commit b51ef8c out. The below commits are in order from bottom to top and are part of those made on 7 April 2020. Bad: commit/f3e971d426a55cd472910eaf659bef1ef969f5c1 Bad: commit/b51ef8cc3c560b6c44d095814988a3f972bc0763 <<<<< OK: commit/1f516f2b0dcdb7d34b6c55e675c41a6cbca3f595 Changes such this one do need to be looked at from the network side and the internal side of linuxCNC. I hope that you will find this helpful. Best regards to all developers. On 10/24/2020 7:33 PM, Johannes Fassotte wrote: There are changes to the NML configuration file Master that concerns me a lot. From the NML configuration file at the start of 2.9 pre0 B emcStatus SHMEM localhost 16384 0 0 2 16 1002 TCP=5
Re: [Emc-developers] EMC Master NML configuration file buffer size changes
I wanted to post a update on this since I have isolated the source of unknown data being intermixed with my status requests data sent via the tcp buffer to my remote. This unknown and not requested data completely disrupts the normal flow of status data at 6 times in a row and this sequence repeats at itself at regular intervals. I have back tracked this problem to 7 April 2020 and commit b51ef8c to "increase max tools from 55 to 1000" and that this has caused a problem from that point forward up to and including the current master. It is also the cause of the very large increase and what I think is an unreasonable increase in NML buffer sizes. I had not done much development work this summer and thus this issue was not noticed until a recent update. It seems to me that a regular file or small database is more than sufficient for a tool table with a choice depending on if pictures are wanted or not. I see absolutely no valid reason for messing around with NML buffer sizes to handle the tool table. I think that the best thing to do is to develop a more suitable way to handle the tool table and backing commit b51ef8c out. The below commits are in order from bottom to top and are part of those made on 7 April 2020. Bad: commit/f3e971d426a55cd472910eaf659bef1ef969f5c1 Bad: commit/b51ef8cc3c560b6c44d095814988a3f972bc0763 <<<<< OK: commit/1f516f2b0dcdb7d34b6c55e675c41a6cbca3f595 Changes such this one do need to be looked at from the network side and the internal side of linuxCNC. I hope that you will find this helpful. Best regards to all developers. On 10/24/2020 7:33 PM, Johannes Fassotte wrote: There are changes to the NML configuration file Master that concerns me a lot. From the NML configuration file at the start of 2.9 pre0 B emcStatus SHMEM localhost 16384 0 0 2 16 1002 TCP=5005 xdr B toolSts SHMEM localhost 8192 0 0 5 16 1005 TCP=5005 xdr Present 2.9 pre0 I use B emcStatus SHMEM localhost 17 0 0 2 16 1002 TCP=5005 xdr B toolSts SHMEM localhost 131072 0 0 5 16 1005 TCP=5005 xdr Such a large change in file size indicates a major change in the method of how some data is handled. I assume that it is associated with a change to txt based data which would need a great deal of space. I have no info on why such a large change in buffer sizes is required in current master. All I know is that these changes are causing problems with use of the remote TCP process that I use to status with and have used successfully for almost a year using the early 2.9 pre0 master. The remote status requests commands I send now using the ~10-14-2020 master gives me the usual 20 byte status request acknowledgement as in the past. Then 10380 bytes of actual emcStatus data, and then at perhaps 1 second intervals a very large block of data is sent by linuxCNC to the TCP buffer that was not requested by my remote. It is mostly what I think is header or a bit of data followed a very large number of bytes of all zero's data. In using the current master for my development has made it impossible to decode the status buffer data remotely when unknown data gets transferred into the TCP buffer that the remote process has not requested. This kills TCP status server due the confusion it causes which build up error until its shuts down. Command serial numbers start getting confused with data being in the wrong place and its all downhill from there. Here again is a size comparision of NML configuration file of the original 2.9 pre0 which works fine to master on about 10-14-2020 B emcStatus SHMEM localhost 16384 0 0 2 16 1002 TCP=5005 xdr B emcStatus SHMEM localhost 17 0 0 2 16 1002 TCP=5005 xdr To me such a tremendous increase in size would seem to indicate an intention to store and send a lot of text formatted data. I could be wrong but when there is a lack of info there has to be a lot of running around in circles and guessing. And based on this leads to the below. Status buffer Msg data 122464 bytes Tool Msg size 112888 bytes I also noticed that the size of the actual emcStatus data has increased from 9280 bytes to 10380 bytes which would seem to indicate added status data. This being the second increase that I recall. Thus far I have been using the xemc process for status data with this latest version of master but will set up a separate status process to see if that gets rid of the undesired data transfer that occurs at about 1 second intervals. xemc is linked into a lot of internal processes within linuxCNC and it is likely that one of those is causing the problem I have attempted to explain. I recalled today that I have seen issues with xemc being used in the past for local functions such as polling and not strictly used just for communications with a remote over a network connection. Please supply some info on what these Status buffer and Tool Msg's contains so I can p
Re: [Emc-developers] TCP remote UI issue with tag RT data ?
Rod, I'm tending to agree after searching more for code associated with tags. At present looking for code that may be active that does some kind of polling or status requests at regular intervals and Includes any that may become active if there is a change in the command serial number due to status peek requests. So far this particular problem has been very allusive which means that I'm looking in the wrong places and don't understand what to look for. But why would something transfer large blocks of data that appears to contain no data (all zeros) and place it in the TCP buffer at the same time a status requests data is being sent back to the remote at specific intervals and do it say six or seven times in a sequence. I have considered that this could possibly be a memcpy routines of some memory space being sent in addition to the actual status data the remote requested. Or perhaps just long strings that have been allocated for use but contain no data for something that is not yet complete. That concept kind of follows the increase in the NML status buffer size in the NML configuration file. Divide that increase by six or seven and it could approximate the total of the fathom data transfer bytes for each iteration. This is just thinking out loud here and likely thinking to much. My number 6 could be 7 if also considering the larger number bytes transferred for number 7 in my lists in which it appears that data in the TCP buffer is piling up, possibly due to being locked out for a bit and not able to pull the data out of the TCP buffer. On 10/28/2020 1:10 PM, Rod Webster wrote: I don't believe the issue is related to state tags. I've done a fair bit of work with extending state tags to include some more useful data as motion pins at run time. All State tags does is add an additional structure to emcStatus that records the interpreter state of a given segment. So the interp primitives update the tags. The only annoyance is that interp is written in C++ and motion is in C. Interp keeps its own C++ status structure which is copied across to emcStatus ( using discrete read and write functions in interp). But that well and truly predates state tags. I recall reading the source notes you refer to and I think what it means is that as long as you use the enums when referring to status bits, it does not matter where the data is stored as the enum applies the correct index to the data. The other issue is that some of the underlying tag data enums are #defined private to interp which requires hard coded numerics on the motion side which is not desirable and could introduce errors. This refers https://github.com/LinuxCNC/linuxcnc/pull/900 Rod Webster *1300 896 832* +61 435 765 611 VMN® www.vmn.com.au On Thu, 29 Oct 2020 at 06:09, Johannes Fassotte < johan...@automationassist.com> wrote: Did the addition of state tags mess up status replies that are routed to my TCP connected UI? Data is being sent even though it was not requested at fixed intervals. This problem appeared after upgrading from a early version of 2.9 pre0 master to current version of 2.9 pre0. master. No changes have been made to it. As far as I know the normal replies to status requests are handled by the emcmaintask at whatever rate is requested by the remote as long as it slower than the timing rate set in the .ini file. The below shows that there are seven data transmissions sent that are causing serious problems at regular intervals. The normal transmission of status data to the remote is in response to a status peek request of buffer 2 and such a request is always constant in size with the location of data within it also being constant unless the LinuxCNC configuration is changed. Inserting a bunch of added data preset intervals is really bad when thinking about this from a remotes point of view. In such a case the remote has to be expecting it and as a minimum need to know the size or length of the data. Neither of those two requirements can be met right now. I suspect that two separate processes are fighting for control with the remote ending up being the looser. A real time process and a none real time process. I have looked at actual length of the data that is causing this issue which may be 72980 bytes. Other other data is likely being merged into it from the remote status peek requests. The long one on the end of each bad data segment is likely the TCP buffer filling up due to the remotes inability to empty it because of being locked out for a while. I'm working around this issue temporarily by pulling the problem data out of the TCP buffer and dumping it. This does cause the loss of some status updates but allows me to continue to work on other UI work. Is the bad data is likely being generated separately by a real time task that sends it out at specific intervals?. The below pattern is repeating over and over. Additional comment at the end. Data error 74272 lenght is not 103716, Ba
[Emc-developers] TCP remote UI issue with tag RT data ?
Did the addition of state tags mess up status replies that are routed to my TCP connected UI? Data is being sent even though it was not requested at fixed intervals. This problem appeared after upgrading from a early version of 2.9 pre0 master to current version of 2.9 pre0. master. No changes have been made to it. As far as I know the normal replies to status requests are handled by the emcmaintask at whatever rate is requested by the remote as long as it slower than the timing rate set in the .ini file. The below shows that there are seven data transmissions sent that are causing serious problems at regular intervals. The normal transmission of status data to the remote is in response to a status peek request of buffer 2 and such a request is always constant in size with the location of data within it also being constant unless the LinuxCNC configuration is changed. Inserting a bunch of added data preset intervals is really bad when thinking about this from a remotes point of view. In such a case the remote has to be expecting it and as a minimum need to know the size or length of the data. Neither of those two requirements can be met right now. I suspect that two separate processes are fighting for control with the remote ending up being the looser. A real time process and a none real time process. I have looked at actual length of the data that is causing this issue which may be 72980 bytes. Other other data is likely being merged into it from the remote status peek requests. The long one on the end of each bad data segment is likely the TCP buffer filling up due to the remotes inability to empty it because of being locked out for a while. I'm working around this issue temporarily by pulling the problem data out of the TCP buffer and dumping it. This does cause the loss of some status updates but allows me to continue to work on other UI work. Is the bad data is likely being generated separately by a real time task that sends it out at specific intervals?. The below pattern is repeating over and over. Additional comment at the end. Data error 74272 lenght is not 103716, Bad data Lenght: 74272 Data Not part of emcStatus Data error 74224 lenght is not 103716, Bad data Lenght: 74224 Data Not part of emcStatus Data error 74276 lenght is not 103716, Bad data Lenght: 74276 Data Not part of emcStatus Data error 74204 lenght is not 103716, Bad data Lenght: 74204 Data Not part of emcStatus Data error 74424 lenght is not 103716, Bad data Lenght: 74424 Data Not part of emcStatus Data error 74436 lenght is not 103716, Bad data Lenght: 74436 Data Not part of emcStatus Data error 280176 lenght is not 103716, Bad data Lenght: 280176 Data Not part of emcStatus 103716 < Data bytes matches with what was sent (maintask) 103716 < Data bytes matches with what was sent (maintask) 103716 < Data bytes matches with what was sent (maintask) 103716 < Data bytes matches with what was sent (maintask) 103716 < Data bytes matches with what was sent (maintask) 103716 < Data bytes matches with what was sent (maintask) 103716 < Data bytes matches with what was sent (maintask) 103716 < Data bytes matches with what was sent (maintask) 103716 < Data bytes matches with what was sent (maintask) 103716 < Data bytes matches with what was sent (maintask) 103716 < Data bytes matches with what was sent (maintask) 103716 < Data bytes matches with what was sent (maintask) 103716 < Data bytes matches with what was sent (maintask) 103716 < Data bytes matches with what was sent (maintask) 103716 < Data bytes matches with what was sent (maintask) 103716 < Data bytes matches with what was sent (maintask) 103716 < Data bytes matches with what was sent (maintask) 103716 < Data bytes matches with what was sent (maintask) 103716 < Data bytes matches with what was sent (maintask) 103716 < Data bytes matches with what was sent (maintask) 103716 < Data bytes matches with what was sent (maintask) 103716 < Data bytes matches with what was sent (maintask) 103716 < Data bytes matches with what was sent (maintask) 103716 < Data bytes matches with what was sent (maintask) 103716 < Data bytes matches with what was sent (maintask) 103716 < Data bytes matches with what was sent (maintask) 103716 < Data bytes matches with what was sent (maintask) 103716 < Data bytes matches with what was sent (maintask) 103716 < Data bytes matches with what was sent (maintask) 103716 < Data bytes matches with what was sent (maintask) 103716 < Data bytes matches with what was sent (maintask) Data error 74272 lenght is not 103716, Bad data Lenght: 74272 Data Not part of emcStatus Data error 74224 lenght is not 103716, Bad data Lenght: 74224 Data Not part of emcStatus Data error 74276 lenght is not 103716, Bad data Lenght: 74276 Data Not part of emcStatus Data error 74204 lenght is not 103716, Bad data Lenght: 74204
[Emc-developers] EMC Master NML configuration file buffer size changes
This is what is happening in relation to the actual traditional emcStatus sync word location, . This list was automatically generated by looking for the locations of the sync word in the data received from LinuxCNC and splitting the received data into before and after segments at that point. Thus it lists the before and after sync word data sizes in relation to the traditional emcStatus sync word. Normally the before sync word location would be 20. As the list show stability of the location of the sync word has been lost by a recent change. For info the status request for this test were made at 50ms intervals. Anything with 20 in the before list will give proper status info. It should be noted that there was no request made by the remote for the problematic data, nor does it show up as having been sent to the remote in debug. Debug does show proper handling of the data that was requested. My tests seem to show that there is no data in these transfers that do not have 20 as a before value, they are just a whole lot of zero's.. Is there any info available how best the disable these data transfer so I can continue on other work? I have done all I can do on this for now. This pattern repeats over and over and over Before: 29360, After: 45068 Before: 58720, After: 15708 Before: 74440, After: 0 Before: 13620, After: 60808 Before: 42980, After: 31448 Before: 72340, After: 127648 Before: 79960, After: 103768 Before: 20, After: 103768 Before: 20, After: 103768 Before: 20, After: 103768 Before: 20, After: 103768 Before: 20, After: 103768 Before: 20, After: 103768 Before: 20, After: 103768 Before: 20, After: 103768 Before: 20, After: 103768 Before: 20, After: 103768 Before: 20, After: 103768 Before: 20, After: 103768 Before: 20, After: 103768 Before: 20, After: 103768 Before: 20, After: 103768 Before: 20, After: 103768 Before: 20, After: 103768 Before: 20, After: 103768 Before: 20, After: 74428 Before: 29360, After: 45068 Before: 58720, After: 15708 Before: 74440, After: 0 Before: 13620, After: 60808 Before: 42980, After: 31448 Before: 72340, After: 127648 Before: 79960, After: 103768 Before: 20, After: 103768 Before: 20, After: 103768 Before: 20, After: 103768 Before: 20, After: 103768 Before: 20, After: 103768 Before: 20, After: 103768 Before: 20, After: 103768 Before: 20, After: 103768 Before: 20, After: 103768 Before: 20, After: 103768 Before: 20, After: 103768 Before: 20, After: 103768 Before: 20, After: 103768 Before: 20, After: 103768 Before: 20, After: 103768 Before: 20, After: 103768 Before: 20, After: 103768 Before: 20, After: 74428 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] EMC Master NML configuration file buffer size changes
I wanted to follow up a bit on my last msg regarding this with some debug and a bit more additional info. The below are the typical responses I get from LinuxCNC when status requests are made from my remote UI. I added some ( ) comments to some lines for additional clarity along with some spaces between each automatic status request. (time=1603662496.783341,pid=3200): Socket opened by host with IP address 10.10.20.1. Ok we are connected so here we go. (time=1603662496.842952,pid=3200): read 20 bytes from 4 (status request from remote was received) (time=1603662496.842977,pid=3200): TCPSVR request received: fd = 4, serial_number=1, request_type=1, buffer_number=2 (time=1603662496.843004,pid=3200): rcs_sem_post(688129) called. (time=1603662496.843248,pid=3200): wrote 20 bytes to 4 (status request acknowledge back to remote) (time=1603662496.843304,pid=3200): wrote 103800 bytes to 4 (status data sent to remote) (time=1603662496.907978,pid=3200): read 20 bytes from 4 (status request from remote was received) (time=1603662496.908000,pid=3200): TCPSVR request received: fd = 4, serial_number=2, request_type=1, buffer_number=2 (time=1603662496.908027,pid=3200): rcs_sem_post(688129) called. (time=1603662496.908292,pid=3200): wrote 20 bytes to 4 (status request acknowledge back to remote) (time=1603662496.908348,pid=3200): wrote 103800 bytes to 4 (status data sent to remote) (time=1603662496.972850,pid=3200): read 20 bytes from 4 (status request from remote was received) (time=1603662496.972873,pid=3200): TCPSVR request received: fd = 4, serial_number=3, request_type=1, buffer_number=2 (time=1603662496.972902,pid=3200): rcs_sem_post(688129) called. (time=1603662496.973146,pid=3200): wrote 20 bytes to 4 (status request acknowledge back to remote) (time=1603662496.973192,pid=3200): wrote 103800 bytes to 4 (status data sent to remote) (time=1603662497.017987,pid=3200): read 20 bytes from 4 (status request from remote was received) (time=1603662497.018011,pid=3200): TCPSVR request received: fd = 4, serial_number=4, request_type=1, buffer_number=2 (time=1603662497.018038,pid=3200): rcs_sem_post(688129) called. (time=1603662497.018268,pid=3200): wrote 20 bytes to 4 (status request acknowledge back to remote) (time=1603662497.018305,pid=3200): wrote 103800 bytes to 4 (status data sent to remote) This sequence continues forever with increasing serial numbers unless stopped manually or due to an error, and will attempt to reconnect forever unless stopped due problems as I have metioned that shuts down the LinuxCNC TCP server. That will not come back alive without a manual restart. As can be seen the first thing sent back to the remote is a acknowledgment with command serial number, like this in hex: 0001 0002 0001 9578 0003 ECA0 0001 is command serial number, and 0002 is the buffer number Following the acknowledgement is the 103800 bytes status data transfer which also has a header and sync pattern of , status data top starts immediately after this pattern. For a bit more clarity the below shows a small portion of a print out and shows the fathom extra data bytes. Only the 103800 byte ones are valid emcStatus data. The rest is data that is causing major system confusion making it very difficult to even maintain a connection between LinuxCNC and the remote to capture this data. The below also shows that some "byte" values of this strange data are piling up in the TCP buffer due to delays in the ability to pull in whatever data this is due to delays caused by errors. These thus show getting closer to a buffer overflow condition which would shut down the TCP server within LinuxCNC. I decided not to capture the 20 Byte status byte acknowledgement in the below list. Not sure why each start of the unknown data is 74460 bytes versus 74440 bytes in the following. It could be a 20 byte acknowledgement to one of the status requests that was not able to be read due to errors and was thus left in the TCP buffer. 74460, 74440, 74440, 74440, 74440, 74440, 270080, 113660, 103800, 103800, 103800, 103800, 103800, 103800, 103800, 103800, 103800, 103800, 103800, 103800, 103800, 103800, 103800, 103800, 103800, 74460, 74440, 74440, 74440, 74440, 74440, 270080, 113660, 103800, 103800, 103800, 103800, 103800, 103800, 103800, 103800, 103800, 103800, 103800, 103800, 103800, 103800, 103800, 103800, 103800, 74460, 74440, 74440, 74440, 74440, 74440, 270080, 113660, 103800, 103800, 103800, 103800, 103800, 103800, 103800, 103800, 103800, 103800, 103800, 103800, 103800, 103800, 103800, 103800, 103800, 103800, 74460, 74440, 74440, 74440, 74440, 74440, 270080, 113660, 103800, 103800, 103800, 103800, 103800, 103800, 103800, 103800, 103800, 103800, 103800, 103800, 103800, 103800, 103800, 103800, 74460, 74440, 74440, 74440, 74440, 74440, 270080, 113660, 103800, 103800, 103800, 103800, 103800, 103800, 103800, 103800, 103800, 103800,
[Emc-developers] EMC Master NML configuration file buffer size changes
There are changes to the NML configuration file Master that concerns me a lot. From the NML configuration file at the start of 2.9 pre0 B emcStatus SHMEM localhost 16384 0 0 2 16 1002 TCP=5005 xdr B toolSts SHMEM localhost 8192 0 0 5 16 1005 TCP=5005 xdr Present 2.9 pre0 I use B emcStatus SHMEM localhost 17 0 0 2 16 1002 TCP=5005 xdr B toolSts SHMEM localhost 131072 0 0 5 16 1005 TCP=5005 xdr Such a large change in file size indicates a major change in the method of how some data is handled. I assume that it is associated with a change to txt based data which would need a great deal of space. I have no info on why such a large change in buffer sizes is required in current master. All I know is that these changes are causing problems with use of the remote TCP process that I use to status with and have used successfully for almost a year using the early 2.9 pre0 master. The remote status requests commands I send now using the ~10-14-2020 master gives me the usual 20 byte status request acknowledgement as in the past. Then 10380 bytes of actual emcStatus data, and then at perhaps 1 second intervals a very large block of data is sent by linuxCNC to the TCP buffer that was not requested by my remote. It is mostly what I think is header or a bit of data followed a very large number of bytes of all zero's data. In using the current master for my development has made it impossible to decode the status buffer data remotely when unknown data gets transferred into the TCP buffer that the remote process has not requested. This kills TCP status server due the confusion it causes which build up error until its shuts down. Command serial numbers start getting confused with data being in the wrong place and its all downhill from there. Here again is a size comparision of NML configuration file of the original 2.9 pre0 which works fine to master on about 10-14-2020 B emcStatus SHMEM localhost 16384 0 0 2 16 1002 TCP=5005 xdr B emcStatus SHMEM localhost 17 0 0 2 16 1002 TCP=5005 xdr To me such a tremendous increase in size would seem to indicate an intention to store and send a lot of text formatted data. I could be wrong but when there is a lack of info there has to be a lot of running around in circles and guessing. And based on this leads to the below. Status buffer Msg data 122464 bytes Tool Msg size 112888 bytes I also noticed that the size of the actual emcStatus data has increased from 9280 bytes to 10380 bytes which would seem to indicate added status data. This being the second increase that I recall. Thus far I have been using the xemc process for status data with this latest version of master but will set up a separate status process to see if that gets rid of the undesired data transfer that occurs at about 1 second intervals. xemc is linked into a lot of internal processes within linuxCNC and it is likely that one of those is causing the problem I have attempted to explain. I recalled today that I have seen issues with xemc being used in the past for local functions such as polling and not strictly used just for communications with a remote over a network connection. Please supply some info on what these Status buffer and Tool Msg's contains so I can possibly develop a process to utilize these if they are really meant to be used across a network and if this will be on a separate status buffer. Rule 1: Never send data to a remote that was not specifically requested, authorized or subscribed to. ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] Problem with check_config.tcl file
I'm working on doing some update work on my development system for my
Labview based UI
and yesterday starting work to make the latest version of master
compatible with
my development system. My present base for this is almost a year old.
I ran into a issue with file: /lib/hallib/check_config.tcl.
I can bypass everything starting at line 170 to 213 and everything loads
and runs fine.
I do notice that Debug is not displaying NML types and their overloads
info while running.
I start my "runinplace" with the below as normal and with lines 170 and 213
of /lib/hallib/check_config.tcl not commented out so errors can be seen
as shown below.
Start command line:
rmcsys /home/cnc/rmc-dev/configs/x1Mill/x1Mill.ini.expanded
The result is:
RMCSYS - 2.9.0~pre0
Machine configuration directory is '/home/cnc/rmc-dev/configs/x1Mill'
Machine configuration file is 'x1Mill.ini.expanded'
cannot find symbol "Rmcsys_Init": /home/cnc/rmc-dev/tcl/rmcsys.so:
undefined symbol: _Rmcsys_Init
while executing
"load [file join [file dirname [info script]] rmcsys[info
sharedlibextension]]"
(file "/home/cnc/rmc-dev/tcl/rmcsys.tcl" line 61)
invoked from within
"source /home/cnc/rmc-dev/tcl/rmcsys.tcl"
("package ifneeded rmcSys 1.0" script)
invoked from within
"package require rmcSys "
(file "/home/cnc/rmc-dev/lib/hallib/check_config.tcl" line 160)
check_config validation failed
RmcSys terminated with an error. You can find more information in the log:
/home/cnc/rmcsys_debug.txt
and
/home/cnc/rmcsys_print.txt
as well as in the output of the shell command 'dmesg' and in the terminal
cnc@cnc1:~/rmc-dev$
The only reference that is close to the missing _Rmcsys_Init is in file:
/src/rmc/usr_intf/rmcsh.cc lines 3551 and 3552.
For my rmc system this is: int rmcSys_Init(Tcl_Interp * interp)
For normal system this is: int Linuxcnc_Init(Tcl_Interp * interp)
I'm looking for any ideas on how to make the undefined symbol:
_Rmcsys_Init happy.
I also noticed that initially it loaded and ran some QT related items
from hidden
/home/.local by just entering "rmcsys" and would not let me continue
because it was unhappy. Deleted all the
QT stuff from the .local folder and as a result runinplace routing
started working as desired.
I will continue to see if I can figure this out but also not sure if some
of these new configuration checks need some additional information in
the .ini file that was
not needed in the past or if perhaps Rmcsys needs to be changed to
rmcSys somewhere.
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Include folder files not copied during recompile
Thanks to every one for checking into this for me. This lead me to the conclusion that the problem was on my system. I had never tried to remove the include folder to make sure it would rebuild properly during a recompile. I found that my issue was that the paths for items related to these were not completely correct in the make file. I have corrected those and things now compile with no errors and the include folder is rebuilt properly. On 10/17/2020 9:17 AM, Johannes Fassotte wrote: I was checking to make sure that all the .h files in the include folder get updated with a recompile and if the folder is properly regenerated automatically if it was deleted. I found that four of the .h files are not being copied back into the folder automatically on my system. I suspect that this may also be the case with current master and perhaps also other versions. This presents a problem with these files not staying in sync with the originals that may have had changes made to them. make: *** No rule to make target '../include/posemath.h', needed by 'headers'. Stop. make: *** No rule to make target '../include/gotypes.h', needed by 'headers'. Stop. make: *** No rule to make target '../include/gomath.h', needed by 'headers'. Stop. make: *** No rule to make target '../include/sincos.h', needed by 'headers'. Stop. Best regards, Johannes ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] Include folder files not copied during recompile
I was checking to make sure that all the .h files in the include folder get updated with a recompile and if the folder is properly regenerated automatically if it was deleted. I found that four of the .h files are not being copied back into the folder automatically on my system. I suspect that this may also be the case with current master and perhaps also other versions. This presents a problem with these files not staying in sync with the originals that may have had changes made to them. make: *** No rule to make target '../include/posemath.h', needed by 'headers'. Stop. make: *** No rule to make target '../include/gotypes.h', needed by 'headers'. Stop. make: *** No rule to make target '../include/gomath.h', needed by 'headers'. Stop. make: *** No rule to make target '../include/sincos.h', needed by 'headers'. Stop. Best regards, Johannes ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Third-Party GUIs
The slow update rate is likely a method issue and not an issue with network speed itself. Most networks can handle speeds of GB per second rates which is much much faster than actually required. Networks are used to stream all sorts of data these days. Lagging behind can indicate a buffer overflow condition due to the receiving process running to slow to to keep up with the data being sent for display. Old code and speed restrictions are likely not designed to overcome that. New methods do require new code to be developed in order to provide excellent results. Johannes P. Fassotte Automation Assist 217 Sunny Hills Drive Fairbanks, AK 99712 > On May 3, 2020, at 7:06 AM, Gene Heskett wrote: > >> On Sunday 03 May 2020 10:17:46 Johannes Fassotte wrote: >> >> The name remote UI should be considered to mean that it is interfaced >> to LinuxCNC using a network connection. This connection for most >> individuals would likely be via local host but it can be used remotely >> if desired from other suitable devices. Such a interface adds >> flexibility and would provide universal interface. >> >> There is little difference between controlling a machine with say an >> Ethernet interfaced Mesa FPGA board or using a Ethernet connected UI. >> Both of these can be considered to be remote. How a user decides to >> use it is totally up to the user since such an interface offers >> tremendous flexibility. >> >> Johannes P. Fassotte >> Automation Assist >> 217 Sunny Hills Drive >> Fairbanks, AK 99712 >> > Haveing had some experience trying to run linuxcnc over an ssh -Y connection > I can say that it works BUT the backplot display I was looking at was also > running very close to a full second behind the machine. This was very > disconcerting and IMO a huge safety consideration in that there is no way one > could see an impending crash and broken tooling in time to stop it. Same for > someone else walking up to the machine and getting in its way. Build it in if > you want to, but its not anything I'd ever try again. > >>> On May 3, 2020, at 4:26 AM, Robert Murphy >>> wrote: >>> >>> I agree, I never saw the sense in a remote UI, other than all the >>> "hipster\makers" want to control the world with their phones. >>> Machinekit, IMHO, seemed to be focused more towards the hobbyist who >>> wants bells and whistles rather than an industrial\commercial scene. >>> Don't take this as having a go, but just an observation. >>> >>> I think Andy (or someone we greater knowledge than myself)may have >>> mentioned that whilst the GUI buttons can made to reflect the state >>> of a hardware button, the reverse is not so simple. I'm not >>> suggesting this is what you have in mind. Whilst a "gui toggle >>> switch" can reflect the state of a hardware toggle switch, the >>> reverse is not really possible. Unless of course the hardware >>> switches in that case were momentary with a light to indicate the >>> status, but would that not complicate hal & physcial wiring. >>> >>> If the GUI was just info only, well that could be a way to make it >>> possible. >>> >>>> On 3/5/20 9:09 pm, Reinhard wrote: >>>> Hi Daniel, >>>> >>>>> It seems some developer at machinekit did some good work there. >>>>> ... >>>>> ... are the best features in machinekit that are missing in >>>>> linuxcnc. >>>> >>>> Hm, I don't think, that a remote ui is something important, that >>>> linuxcnc is missing. And I don't take the nml-layer for bad so that >>>> it must be replaced. For me, nml-layer is a good piece of C-code, >>>> which was easy to adapt for java. The bad thing is the python >>>> addon, which can't be worse. >>>> >>>> So beside the remote accessibility I don't see any feature (in >>>> userworld) that machinekit has, which linuxcnc does not have. And >>>> replacing the middleware without benefit for the enduser is lot of >>>> time wasted (at least for me). >>>> >>>> For me, a machine is a local system. Some users would like to have >>>> an UI running on their mobile phone, but I can't take that for >>>> serious. May be acceptable as info board, but not for machining >>>> purpuse. And an infochannel is quite easy to workout as addon. >>>> >>>> That remote stuff could be "outsourced" to developers, that really >>>> want that stuff and like to spend
Re: [Emc-developers] Third-Party GUIs
The name remote UI should be considered to mean that it is interfaced to LinuxCNC using a network connection. This connection for most individuals would likely be via local host but it can be used remotely if desired from other suitable devices. Such a interface adds flexibility and would provide universal interface. There is little difference between controlling a machine with say an Ethernet interfaced Mesa FPGA board or using a Ethernet connected UI. Both of these can be considered to be remote. How a user decides to use it is totally up to the user since such an interface offers tremendous flexibility. Johannes P. Fassotte Automation Assist 217 Sunny Hills Drive Fairbanks, AK 99712 > On May 3, 2020, at 4:26 AM, Robert Murphy wrote: > > I agree, I never saw the sense in a remote UI, other than all the > "hipster\makers" want to control the world with their phones. > Machinekit, IMHO, seemed to be focused more towards the hobbyist who > wants bells and whistles rather than an industrial\commercial scene. > Don't take this as having a go, but just an observation. > > I think Andy (or someone we greater knowledge than myself)may have > mentioned that whilst the GUI buttons can made to reflect the state of a > hardware button, the reverse is not so simple. I'm not suggesting this > is what you have in mind. Whilst a "gui toggle switch" can reflect the > state of a hardware toggle switch, the reverse is not really possible. > Unless of course the hardware switches in that case were momentary with > a light to indicate the status, but would that not complicate hal & > physcial wiring. > > If the GUI was just info only, well that could be a way to make it possible. > >> On 3/5/20 9:09 pm, Reinhard wrote: >> Hi Daniel, >> >>> It seems some developer at machinekit did some good work there. >>> ... >>> ... are the best features in machinekit that are missing in linuxcnc. >> Hm, I don't think, that a remote ui is something important, that linuxcnc is >> missing. And I don't take the nml-layer for bad so that it must be replaced. >> For me, nml-layer is a good piece of C-code, which was easy to adapt for >> java. >> The bad thing is the python addon, which can't be worse. >> >> So beside the remote accessibility I don't see any feature (in userworld) >> that >> machinekit has, which linuxcnc does not have. And replacing the middleware >> without benefit for the enduser is lot of time wasted (at least for me). >> >> For me, a machine is a local system. Some users would like to have an UI >> running on their mobile phone, but I can't take that for serious. May be >> acceptable as info board, but not for machining purpuse. And an infochannel >> is >> quite easy to workout as addon. >> >> That remote stuff could be "outsourced" to developers, that really want that >> stuff and like to spend their time to achive it. >> >> I believe, that the main purpose of linuxcnc is and should be the control of >> machines. In the sense of realtime responses, it is reasonable, to have all >> processes local to the machine controller (i.e. the pc that runs linuxcnc). >> >> What I really favor is a close coupling between backend and frontend. But >> that >> coupling must respect the realtime requirements of the backend. Frontend is >> always ok to be somewhat slow - as the human eyes are slow. >> So it does make no sense at all, have a UI which has an refreshrate higher >> than 24Hz. Nobody can see the difference. >> So coupling should relax the different timings. >> >> cheers Reinhard >> >> >> >> >> >> ___ >> Emc-developers mailing list >> Emc-developers@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/emc-developers > > > ___ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Third-Party GUIs
Here are my thoughts on user interfaces. Frankly I think that just a mention that users can make their own user interface would be enough and how to do that using a universal user interface method. In my opinion all user interfaces should be removed from LinuxCnc proper which will greatly reduce maintenance and upgrade problems. As a example we’re still using Python 2.7 even though there has been talk about upgrading it for years. Perhaps a totally new version of LinuxCnc should be considered instead of adding more and more to the old. It does look to me that Qtpyvcp will be the winner in user interfaces. Johannes P. Fassotte Automation Assist 217 Sunny Hills Drive Fairbanks, AK 99712 > On May 1, 2020, at 4:17 AM, andy pugh wrote: > > I wonder if the docs should mention the GUIs that are made for > LinuxCNC but are not part of LinuxCNC? > > I am thinking of > http://www.qtpyvcp.com/showcase/mill_vcps.html > And > https://github.com/DjangoReinhard/JCNCScreen > > And maybe also PathPilot. > > -- > atp > "A motorcycle is a bicycle with a pandemonium attachment and is > designed for the especial use of mechanical geniuses, daredevils and > lunatics." > — George Fitch, Atlanta Constitution Newspaper, 1912 > > > ___ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] State-synch G-code.
I don’t know. This is not something that I have looked into. My comment is just my feeling that if there is a problem that the source of that problem needs to be identified and fixed and not worked around by adding more code. I’m thinking that a queue can report which item is being executed and send info to user space. Motion should be executing that item and it should also be able to update user space. I’m I thinking wrong? Convert some to kernel modules like in OpenCN? Johannes P. Fassotte Automation Assist 217 Sunny Hills Drive Fairbanks, AK 99712 > On Apr 9, 2020, at 6:21 PM, andy pugh wrote: > > On Fri, 10 Apr 2020 at 03:13, Johannes Fassotte > wrote: >> >> No, I think that is covering up a problem instead of fixing the problem. > > And what do you think that problem is? > > -- > atp > "A motorcycle is a bicycle with a pandemonium attachment and is > designed for the especial use of mechanical geniuses, daredevils and > lunatics." > — George Fitch, Atlanta Constitution Newspaper, 1912 > > > ___ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] Looking to make hex offset list for NML status shared memoryr
Can anyone give me some information on how to pull out the actual shared memory location offset for each item as it is written to status by NML and what is used as its reference point? Any help will be greatly appreciated. I can deal with values but pointers and converting them are a real problem for me. I have found the offsets required for quite a few status items using my remote UI development tools but I would like to generate a complete offset list of all NML status items on the NML side and pass those offsets to the remote UI for decoding use. This is my status peek process from my remote UI. From my remote Labview based UI I peek into status with my NML status peek command and I receive back a 20 byte status request verification. Almost immediately I get back the actual raw copy of the shared memory status data which is 9280 bytes long. Breaking these raw 9280 hex status bytes down: The first 20 bytes is status prefix (not used for now). Next 12 bytes is a sync pattern of ( ). The next 9248 bytes is the actual raw status data. To decode the raw status data I use an offset value starting right after the 12 byte sync pattern as a zero reference point. The 12 byte sync pattern must be decoded properly as part of the logic before any further decoding is allowed. Sample offsets: As an example hex offset 1068 with a decoded length of 72 bytes contains the actual position data for all axis. This is then broken down in 8 bytes increments to get the position value for each axis. As another example a hex offset of 95 with a decoded length of 12 bytes gives the current line number. Since I'm dealing with a raw copy of the status shared memory I hope to be able to find a quick way of pulling out the offsets used my NML itself to help decode all of the stored vales properly. I have decoded quite a few values now just by looking into the raw received status data but the process has been very time consuming. I can see some issues with the serial numbers contained in the status raw data: The peek command also updates the command serial contained in the shared status memory and also updates what I believe to be the total command count accumulator in the shared status memory. This makes it difficult compare old shared memory values to new shared memory values since these two are always changing and thus need to be filtered if doing an old to new compare of actual status data changes and not triggered by the constant serial number changes. ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] A note on my prior Question for iocontrol v2
This was not a iocontrol issue at all but rather I discovered or ran
into a CMS issue while adding NML types for HAL pins for use with TCP
connected remote UI (Rpin's). The below refer to file /nml_intf/emc.cc
(rmc.cc for me).
In my configuration the below are valid for ::update(cms) messages in
the emc.cc file.
RMC_CMD_MSG
RMC_SPINDLE_CMD_MSG
RMC_LUBE_CMD_MSG
RMC_COOLANT_CMD_MSG
RMC_IO_CMD_MSG
RMC_JOINT_CMD_MSG
RMC_JOG_CMD_MSG
RMC_TOOL_CMD_MSG
RMC_TASK_CMD_MSG
RMC_TRAJ_CMD_MSG
RMC_AUX_CMD_MSG
RMC_MOTION_CMD_MSG
RMC_RPIN_CMD_MSG
The below example is part of NML type additions for my Rpin's to
/nml_intf/emc.cc.
/* NML/CMS Update function for RMC_RPIN_MACHINE_CNC */
void RMC_RPIN_MACHINE_CNC::update(CMS * cms) {
RMC_RPIN_CMD_MSG::update(cms);
}
If the last line above has an invalid entry such as the below and the
remote command RMC_RPIN_MACHINE_CNC is executed:
RMC_RPIN_MACHINE_CNC::update(cms);
The system will no longer accept any commands after the RMC_RPIN_MACHINE_CNC
command is given from a remote UI that is using TCP into port 5005.
It does not terminate the connection but a LinuxCnc restart is
required to restore to working condition. Thus it appears that CMS
becomes none responsive.
I would expect that in the case of such an error that an error message
would be generated and that the system would recover and not become
totally none responsive. But there is no debug message generated and it
appears to be an issue with CMS in that it is not able reject such a
command or recover from it after attempting to execute it.
The effect of this is: Decreases system reliability
My added HAL Rpin's are working properly.
The sample shown is part of switching logic that changes the machine
from CNC mode to legacy Manual mode.
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] Question for iocontrol v2
Not sure if this is an issue with a unmodified version of iocontrol v2 or
potentially related to my own version which adds some pins that are
controlled by my remote UI that interfaces directly with NML via xemc
(xrmc for me). RMC = abbreviated Remote Machine Controller
I have been running fine until I started using iocontrol. In running
with iocontrol I choose to use v2 from 2.9 pre 0 and modified it only
to add some pins that are remote UI related for HAL. The problem is that
the NML remote process server itself becomes none responsive after
TOOL_ABORT reason=2 is sent right after a machine power on command.
Don't know
why it would even send this command during a basic machine power up
sequence that does not involve a tool change.
Below is a copy and paste that show the command sequence used to run
into the problem.
Remote connection watch dog polling in these are types:
(time=1580516452.319145,pid=2428)
1st remote UI command sent after remote NML connection estabished
Issuing RMC_TASK_SET_STATE -- ( +505,+24, +1, +1,)
IO CMD - RMC_AUX_ESTOP_ON
IO CMD - RMC_LUBE_OFF
NML_INTERP_LIST(0x561fbe3a9a00)::clear(): discarding 0 items
NML_INTERP_LIST(0x561fbe3a9a00)::append(nml_msg_ptr{size=24,type=RMC_TASK_PLAN_SYNCH})
: list_size=1, line_number=0
rmcTaskPlanSynch() returned 0
NML_INTERP_LIST(0x561fbe3a9a00)::get(): {size=24,
type=RMC_TASK_PLAN_SYNCH}, list_size=0
rmcTaskPlanLevel() returned 0
task: main loop took 0.047238 seconds
IO CMD - RMC_TOOL_ABORT reason=6
Issuing RMC_TASK_PLAN_SYNCH -- ( +516,+24, +0,)
rmcTaskPlanSynch() returned 0
(time=1580516452.319145,pid=2428): read 20 bytes from 6
(time=1580516452.319170,pid=2428): TCPSVR request received: fd = 6,
serial_number=6, request_type=1, buffer_number=1
(time=1580516452.319189,pid=2428): rcs_sem_post(196608) called.
(time=1580516452.319221,pid=2428): wrote 20 bytes to 6
2nd remote UI command sent
Issuing RMC_TASK_SET_STATE -- ( +505,+24, +2, +2,)
IO CMD - RMC_AUX_ESTOP_OFF
NML_INTERP_LIST(0x561fbe3a9a00)::clear(): discarding 0 items
NML_INTERP_LIST(0x561fbe3a9a00)::append(nml_msg_ptr{size=24,type=RMC_TASK_PLAN_SYNCH})
: list_size=1, line_number=0
IO CMD - RMC_TOOL_ABORT reason=5
rmcTaskPlanSynch() returned 0
NML_INTERP_LIST(0x561fbe3a9a00)::get(): {size=24,
type=RMC_TASK_PLAN_SYNCH}, list_size=0
rmcTaskPlanLevel() returned 0
task: main loop took 0.024445 seconds
Issuing RMC_TASK_PLAN_SYNCH -- ( +516,+24, +0,)
rmcTaskPlanSynch() returned 0
(time=1580516511.336288,pid=2428): read 20 bytes from 6
(time=1580516511.336314,pid=2428): TCPSVR request received: fd = 6,
serial_number=36, request_type=1, buffer_number=1
(time=1580516511.336333,pid=2428): rcs_sem_post(196608) called.
(time=1580516511.336367,pid=2428): wrote 20 bytes to 6
3rd remote UI command sent and also IO PWRSSR on (Spindle 240VAC power
solid state relay on).
PWRSSR is handled by IO and routed to hal
Issuing RMC_TASK_SET_STATE -- ( +505,+24, +4, +4,)
IO CMD - RMC_UI_PWRSSR_ON
NML_INTERP_LIST(0x561fbe3a9a00)::clear(): discarding 0 items
NML_INTERP_LIST(0x561fbe3a9a00)::append(nml_msg_ptr{size=24,type=RMC_TASK_PLAN_SYNCH})
: list_size=1, line_number=0
IO CMD - RMC_TOOL_ABORT reason=2
NML_INTERP_LIST(0x561fbe13ee80)::clear(): discarding 0 items
rmcTaskPlanSynch() returned 0
Issuing RMC_TASK_SET_MODE -- ( +504,+24, +5, +1,)
NML_INTERP_LIST(0x561fbe3a9a00)::get(): {size=24,
type=RMC_TASK_PLAN_SYNCH}, list_size=0
rmcTaskPlanLevel() returned 0
Issuing RMC_TASK_PLAN_SYNCH -- ( +516,+24, +0,)
rmcTaskPlanSynch() returned 0
(time=1580516665.491116,pid=2428): read 20 bytes from 6
(time=1580516665.491142,pid=2428): TCPSVR request received: fd = 6,
serial_number=115, request_type=1, buffer_number=1
(time=1580516665.491160,pid=2428): rcs_sem_post(196608) called.
(time=1580516665.491195,pid=2428): wrote 20 bytes to 6
After this if one additional command is sent the NML server for the
remote process becomes
none responsive and polling replies back to the remote also stop.
Connectivity
itself is still maintained.
Since direct interface into NML from a remote UI is not used by many is
it possible that problem may be a hidden one? I'm investigating this
issue further but have no additional info right now. I do need a method
to insure that the remote NML process server always stays responsive to
commands. The remote UI is able to automatically reconnect if the
connection is lost for some reason.
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] Question for halmodule
I have noticed that when compiling halmodule.cc in 2.9 pre 0 that it complains that HAL_PORT is not being handled in the switch statements on lines 314, 322, 1001, 1023, 1038. Is this something that needs to added or can can it just be ignored.? ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
