Labview UI project for Linuxcnc

In one of my prior posts I had noticed this problem:

rmcTrajSetAcceleration(3.0000) returned 0
rmcTrajSetMaxAcceleration(999999999999999967336168804116691273849533185806555472917961779471295845921727862608739868455469056.0000)

Very large number in TrajSetMaxAcceleration that should not be there. While working on memory pointers for motion,traj and processing them for possible conversion the results gave me several zero conversion values. In order to process the pointer values into decimal values the 0x prefix of the pointer value has to be removed. There are two pointer values being returned by linuxCNC for me in my system that automatically puts a space character in front of the 0x pointer value prefix, (motion.traj.maxAcceleration and motion.traj.probe_tripped). If while space elimination while using these two pointer value is not used the pointer value will be incorrect.

This is part of my printout and I have checked this a number of times and the extra space always appears and not part of my code.
My development version is based on 2.9pre(0) at this time.

motion.traj.acceleration,T_DOUBLE,0x55edaf814a98
motion.traj.maxVelocity,T_DOUBLE,0x55edaf814aa0
motion.traj.maxAcceleration,T_DOUBLE, 0x55edaf814aa8 <<<< Here
motion.traj.probe_tripped,T_BOOL, 0x55edaf814af8 <<<< Here
motion.traj.probing,T_BOOL,0x55edaf814af9
motion.traj.probeval,T_INT,0x55edaf814afc

I think when you notice bugs like this, you should raise an issue with Linuxcnc here:
github.com/LinuxCNC/linuxcnc/issues

There is still a lot happening to get Python 3 bedded down....

That might could be cause by an entry in the TRAJ section of your INI...

If you have [TRAJ] MAX_LINEAR_VELOCITY try changing it to [TRAJ] MAX_VELOCITY and see what does (or does not) happen.

Cheers,
Kurt

My current way for getting the shared memory offsets for the status memory appears to be working well and I generated a NML command to get the offset for a long list of items that status normally supplies that I made from complete searches in every file of linuxCNC. However there are items that have offsets reported back that place them outside of the the length of the actual status shared memory. I suspect that those could actually be pointers to the shared memory "file" that Python related processes use and that those are available not presently available by requesting a status updates directly from buffer 2. I was always under the impression that status in buffer 2 means all status and not just part of it.

In my efforts to resolve this I have re-coded the Python shared memory file to be handed by a buffer and server instead of being a file. It is not complaining about this change but it does not yet respond to commands from the network. Not sure if this will work out or not but figured it would be worth a try if I could figure out what commands are needed to get some kind of response back. It responds to a buffer ID request but nothing else. Still working on this every now and then.

I decided to take a break on this and do some updates in the GUI which I will post pictures of in my next post.

For many years I have gotten used to real equipment that contained lots of switches, lights, indicators and such that were mostly colored in different shades of gray. The exceptions being buttons that changed color depending on their current state. Even buttons on computer screens was made to look like real hardware. But this trend has changed and now a flat look for almost everything appears to be acceptable.

So to get into this new way of doing this I'm changing all the buttons in my Labview UI to the flat look and also did some re-arranging of various panels hat are called up which is a very easy thing to do.

Here are some pictures of that work.



I think I will leave the keyboard as is.

Researching best practice HMI design is very interesting. Colour should only be used to draw the eye to a problem. I think if you review the literature, you may find you are still using too much colour..

I have a pressbrake control that does this quite well. The theme is green and grey. System calculated values are boring, values the user has changed are in green and values that are preventing a job from running are shown in red.

KCJ wrote:

That might could be cause by an entry in the TRAJ section of your INI...

If you have [TRAJ] MAX_LINEAR_VELOCITY try changing it to [TRAJ] MAX_VELOCITY and see what does (or does not) happen.

Cheers,
Kurt

I did check my .INI file and the value there is 1.5

I will eventually track this down,

I'm running into a issue with jogging while working on some updates for jogging in my UI that
added "axis" and "joint jog" mode buttons and found some things that cause a lot of confusion.

The confusion is related to the sequence of the overload variables in the files listed below.
Please note that the line numbers are for my development system.

shcom.hh(107): extern int sendJogStop(int jnum, int jjogmode);
shcom.hh(108): extern int sendJogCont(int jnum, int jjogmode, double speed);
shcom.hh(109): extern int sendJogIncr(int jnum, int jjogmode, double speed, double incr);

emc.hh(382): extern int emcJogStop(int nr, int jjogmode);
emc.hh(383): extern int emcJogCont(int nr, double vel, int jjogmode);
emc.hh(384): extern int emcJogIncr(int nr, double incr, double vel, int jjogmode);
emc.hh(385): extern int emcJogAbs(int nr, double pos, double vel, int jjogmode);

And copies of the emc.hh file that gets put here after a compile:

\includee\emc.hh(382): extern int emcJogStop(int nr, int jjogmode);
\include\emc.hh(383): extern int emcJogCont(int nr, double vel, int jjogmode);
\include\emc.hh(384): extern int emcJogIncr(int nr, double incr, double vel, int jjogmode);
\include\emc.hh(385): extern int emcJogAbs(int nr, double pos, double vel, int jjogmode);

Below is a part of each line in emc.hh that shows were confusion is taking place.

JogStop(int nr, int jjogmode);
JogCont(int nr, double vel, int jjogmode);
JogIncr(int nr, double incr, double vel, int jjogmode);
JogAbs(int nr, double pos, double vel, int jjogmode);

It looks like jjogmode was just added on on the tail end when it should always remain
in the same location, as it does in shcom.hh.


I have changed the above four lines to the below in my system and will looking to see what other
changes need to be made due to these changes.

----

JogStop(int jnum, int jjogmode);
JogCont(int jnum, int jjogmode, double vel);
JogIncr(int jnum, int jjogmode, double vel, double incr);
JogAbs(int jnumr, int jjogmode, double vel, double pos);

In shcom.hh I changed "speed" to "vel".

----

My issue is that my jogstop commands are excepted in continuous jog mode by LinuxCNC but jogging never stops.
As I recall the joint "jjogmode" was never used in the past so I'm leaning that it could be associated
with my problem. From what I can see the added jjogmode number that I send is not showing up in debug messages of the
received NML jog command message. The other variables, axis and vel show up fine. Nothing follows the last comma right
after the velocity variable. I have read that there have been other reports of no jog stop but don't know how old those reports are or if they are associated. Working on this issue now.

I don't know what JogAbs was meant to be used for.

I recently started using the latest master so that I would get to far behind some of the additions and changes that may have been made without my usual renaming to RMC vice EMC. Thus I'm working with a unmodified master. Everything is working fine with the TCP command NML interface but not so much for the status one that peeks at the emcStatus buffer 2. With the latest version of master there is data sent to the remote that was not requested an is not part of the emcStatus data and is also not part of the data that linuxCNC sends back immediately after sending its status request acknowledgment

The unknown data that is sent back is actually 6 separate data transmission that replace the normal status data but in a format that is unknown and this data does not send an acknowledgement to my status request of any kind. A acknowledgement to a status request is required since it has the command serial number of the command that requested the data, along with buffer number it was sent to and the amount of data bytes that will be sent right after the acknowledgment which is the actual status data from the emcStatus buffer. The acknowledgment message has a length of 20 bytes.

The 6 data burst that are being transferred with unknown data and intended use are typically, 74308, 74276, 74204,74204, 74220 and 280356 bytes long but the number of bytes will vary., A search within this unknown data does show that some does contain the emcStutus sync word of FFFF FFFF FFFF FFFF FFFF FFFF which is present at the head of the status data itself but the position of this within the unkow data varies all over the place and status data is either invalid invalid or incomplete. This problem did not exists in the early version of master I was using which does not have a lot of the RTAPI items that appear to have been added. This unknown data does appear to be sent a fixed intervals that follow the status request rate to some degree.

The below picture as shows the captures of data sizes while remote status requests are send to buffer 2. When Ok is displayed the data bytes match what linuxCNC says it is sending in the acknowledgement message allowing status information to be properly decoded.



The below is a picture of the TCP Labview code that I use in the decode process with some added displays and notes for clarity. The code in upper right is doing the capture work. Length of the current and actual emcStatus data is 103716 bytes and size changes overtime due to updates within linuxCNC and it is thus important to decode the status reply acknowledgement message so that the proper number of bytes can be read by the next TCB buffer read to keep everything in sync.



The picture below display the contents of the false, bad unknown data case. This case is required for now to purge any data from the TCP buffer because the type of data and its content are unknown. Any data sent to the status port by linuxCNC is read and after 5ms has passed the length of data there is determined and stored in the loop on the upper right in the picture above for evaluation. The maximum size of the data allowed to be read is 500000 bytes which is sufficiently large to insure the data is not truncated before the length is determined.



These transfers of unknown data are very likely merging with the actual status replies by attaching themselves to the actual emcSatus buffer data.head or tail in a haphazard way.

I have posted some information like this on the developers net but one has come forward yet to explain exactly what this unknown data or where it is coming from. From what I can see it is just big blocks of all hex zero's. What makes this somewhat more difficult to track down is that not many people use the data that is normally available via the TCP server, even when there is no remote configured in the NML configuration file.

I do Thank Rod for his comments on the developer net.

I would suggest using git bisect to (hopefully) find the commit that caused it.

Chris