On Thursday 05 November 2020 23:20:48 Johannes Fassotte wrote: > 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-linuxc >nc
So labview, which I'm not using, is the basis for yet another gui. OK. NP with that as long as it behaves itself. That however covers a lot of territory. What I am doing is exporting via ssh, the whole gui to another machine. And the status reports are to the extent I can compare them, identical on the remote machine, with what I can see on the local machine, except for the rpi4 build of master. That status display is updated for any change, like starting the spindle. This is for 2.8 on a buster install, master on a wheezy install, master on stretch, and master on raspian buster self built shortly after noting by email from a cron script that does a periodic git pull, that is done by hand and is done within a few hours of noting commit activity on the rpi4... > 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. "tool" is ssh, sshfs? I cannot imagine someone unfamitiar with those file sharing tools. Handier than the turn latch on the outhouse door at a family re-union. I can do anything on any machine as long as I own the file. If I don't own the file, sudo -i, then su owner -c "/path/to/command -options list" just works. But as an axis user who cannot see this problem, I'll bow out as it does not appear to apply to axis users. > 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? Only the tool(s) loaded into the spindle(s in a multiple spindle machine.) > What values for each tool does real time actually actually use for > machining and not for moving tools around? An uptodate Tool # vs pocket # should be sufficient, and at 1000 tools, is a sizeable hunk of int sized buffer, best kept in a database itself. To me, 1000 tools from 55, was too big a jump, 250 could be kept in a byte sized per item DB. How many actual pockets are there in a big machineing centers tool chain?. Thats not saying there aren't more tools, but they should be kept in rack storage, and only loaded into the chain for the job. At some point, time to run the chain becomes a sizeable bit of downtime, so there is a point of diminishing returns. But I'm not ford or gm or? My opinion is one of many IOW. > I Hope this helps. > Thank you Johannes. [...] Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis Genes Web page <http://geneslinuxbox.net:6309/gene> _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
