Advanced Search

Hi Spumco!
Yes, I am just designing the PCB that’s controls it. The bottom part (plc user buttons + normal stuff like start, stop, coolant on/off, etc) goes to the ethercat board. The keyboard I made a USB board that connects directly to the pc and it is seen as a normal HID keyboard but it sends “special combinations” for menu select, machine and so on


regarding the $iemens like modifications it is comming along really well! Not finished yet the new version but basically I got rid of the INI file, made a parameters table (machine, channel, axis), added support for multichannel (basically you can control group axis in different channels and run different gcode in each at the same time (for example in twin turrets lathes). For doing all these stuff I basically rewrote the cnc, everything in C++ (got rid of C as each channel is implemented as a C++ class). Got rid also of NML (replaced by zeromq and capnproto) so it is easier to add new commands as NML is a good but old piece of software. Replaced the rs274 interpreter for a 100% $iemens compatible one so now I have all nice commands like goto, gotof, gotos, repeat from to, etc… 
I removed the o#number thing! This was what I hated the most! Also now subprograms are just searched by file name in same directory structure as $iemens, (current dir-> spf dir-> cus dir->…) 
concerning to GUI I am finishing adding “countour gui” for graphically draw a contour and write gcode automatically (check attachment)

when the project is more advanced I will post more info and tests 

bye!
Franco

I'm looking at the histogram image, but feeling a little lost.

How to interpret the results... how to deduce the CPU speed ?

It looks quite tidy. None of the outliers I recall from before, so maybe that was a bogus memory
I guess the histogram is explained in the docs or here somewhere- will have a search for an explanation that clicks with me.

Regarding the slow ping rate to the Mesa card... that feels like it should be an issue, and could also explain the failure of the HAL test to detect the switches changing state...?

Does the latency test communicate with the MESA card over the network connection, or is that latency test purely between the CPU and software?
 

The networking cards are:
qty 2 of RTL8111/8168/8411  and 
qty 1 of RTL8821CE wireless

All are operable from within linuxcnc desktop, although I disabled the wireless and unused LAN port after installing things, in-case that might help (though it didn't seem to make a difference).

The histogram result is attached. I've also added 6 more images to the original google photos link above. (both before and after running 6 cogs).

Finally, the ping result is also attached.
That seems odd (and maybe another clue?)... why is a local ping taking longer than ~1.4ms... Maybe it's supposed to for the Mesa card, but makes we wanna go hmmmm.... 

Thank you @rodw

Some extra info for clarity:

The "Get CPU Speed" is a button, which when clicked requests the OS user password, and then fills out the value (792 MHz in this case).

By comparison, when using another PC (the old Pentium), clicking that same button retrieves the correct speed for that machine (1800 MHz as I recall). - That is the reason I wondered if the MesaCT software was unable to read the correct CPU info from the mini-PC, for whatever reason.

But that said, the other elephant in the room is the HAL test failing to respond to the button presses, which could be just related to the speed issue, or maybe suggest some other more general comms issue, perhaps with the ethernet control chip in the mini-PC.

I will get to the machine, grab the Realtek type number, and also re-run that latency-histogram, and post the results. I recall seeing odd outliers compared to the pentium, but silly me, I didn't take a photo at that time.

Thanks Phillip! I thought of something to try and hopefully I'll be at the machine later today to try this. If I re-set the safe height from the prefs after changing the range in the USER_COMMAND_FILE then I think it should work fine.

So then the user command file would be:
I'll let you know of that works, so no need for you to try and come up with something for now, but thank you!

Scott

That number is not really the cpu speed. To see it, type
latency-histogram --nobase --sbins 1000

So what is it? TMAX reports performance in timer ticks, not MhZ so it does some maths to convert it to MhZ.
The servo thread takes 1000 usec, We want the Tmax to be < 70% of this so there is some overhead for latency.
I have never used the program you are using as its not part of linuxcnc. . Looks liike its converted TMAX to MhZ. CHeck some of the other drop downs.

hello guys,
i have 5 axis milling cnc machine and i want to use tool setter to measure the tool length, i am using versa probe and m6 remap ngc code as given from qt dragon documentation  (  linuxcnc.org/docs/html/gui/qtdragon.html#_auto_tool_measurement ) , what i expected to be done is as follows:
1- Manual Change tool
2- probe down to Tool setter
3- calculate the tool length
4- update the tool table

what qt dragon do is that it needs the probe height and workpiece height  and calculate the distance between them to be able to set the the tool length by using this equation (Probe result - diff between probe height and workpiece height), from my knowledge in tool length meseurment there must be tool length reference and the tool length is the diff between tool reference length and the tool length measured. i want to calculate the actual tool length.
can someone help me it has been 2 weeks stuck in this problem !!!

Hi, everyone. In the LinuxCNC source code, there should be a directive like IniFile->Find(, “SERVO_PERIOD”, ) to initialize SERVO_PERIOD, but why can't I find it? Also, I found in the motion.c file that SERVO_PERIOD_SEC is given by the system and this value does not change based on the ini file.

Maybe have a look at the simulation configurations using limit3 in the folder 'configs/sim/axis/extrajoints'

cncwhacko wrote:

I connected stlink to my nvmpg to get a dump of the running firmware, it would be interesting to get a copy from someone that has a working to see if there's major difference? Scott, would you be able to take my .bin from my nvmpg and see if it differed from yours? I dont have the skills to reverse engineer things like you did up front but happy to poke about and learn more!

Great, yes please send me your bin file from the NVPMG and I can compare to the one from mine that was use to reverse engineer the payload. It will be interesting to see if they have made some changes.

disneysw wrote:

I have read the full thread, wiki and looked at git hub and there are a number of things I am still confused about due to conflicting information.

I am using a standard LinuxCNC distro on an i5 PC. I have erased and programmed an NVEM V5 board (RT1052) using pyocd and the remora-rt1052-NVEM-0.2.1.bin and the board responds to pings at 10.10.10.10.

I cannot upload a config to the remora board due to time outs, but I understand this is to be expected as the firmware has a full config built-in - is this correct or is this the root cause of my issues?

The board outputs the following via the debug port on boot:

        Initializing PHY...

         ## Entering SETUP state


         ## Entering START state

          Starting the threads

         ## Entering IDLE state

I have installed the remora components (remora-eth, remora-nv, remora-nvmpg) into LinuxCNC and I copied various remora configs to my config directory.

Satrting LinuxCNC and using the remova-nv config I can get the x & y steppers to sort of move but I cannot see any inputs change state (I have tried all of them). In the HAL viewer I can see the Remora status as OK and both the servo-thread.time /remora.update-frq.time are updating.

Ultimately I want to set this up for a lathe with x,y and spindle control but for now it is sitting on my desk with two steppers and some switches wired up to the inputs.


So my questions are:

1: have I flashed the correct firmware?
2: do I need to upload a config file to the NVEM - if so why would I get a timeout (this is mentioned by someone else in an earlier post)?
3: If the above is OK why can I not see any input changes?
4: Do anyone have a Lathe config as a starting point?

Thanks in advance

The default config within the firmware has only three step generators configured. You will need to upload a config, but strange you are getting timeouts..

Hi all!

I've tried installing linuxcnc to an N100 mini-pc (Alder Lake N100, 16GB RAM, 512GB ROM).
      mfg specs : S1 vertical mini pc with 12th generation Intel Alder Lake-N100 processor (up to 3.4GHz, 6MB L3 cache), 20W TDP.
Connected to a MESA 7i96s card with new tested 30cm long CAT6 FTP/S cable. (and also tried unshielded during troubleshooting)

All was easy with the install- the latest linuxcnc debian amd64 iso was used, setup with pnfconf, and the newly installed linuxcnc OS runs (albeit with some timing/latency warnings).

Tried the HAL monitor, but couldn't see responses to any limit or estop button press. (Electrically the voltage swing is 24v to 0v, and the MESA board LEDs blink from bright-on to fully-off as each button is pressed - confident not a wiring issue). 

So next I installed MESACT.Tried the PC/Servo Thread Test, and maybe a clue....

the "Get CPU Speed" button returns only 792 MHz.

Whereas the N100 should be running much faster. In BIOS I believe I had set "Max turbo mode". (images attached).

At this stage I am thinking of three routes to investigate...
1. Is a BIOS setting preventing the mini-PC from reporting it's correct speed to linuxcnc ?
2. Is a missing driver in linuxcnc preventing the OS "seeing" the correct cpu speed ?
3. Something else...

I've attached a complete set of photos of the mesact test, the actual PC and all of the BIOS windows.

I have the C- States set disabled (as in photo IMG_529), but also took a photo of that setting enabled (IMG_0517) just to show the sub-options available.

To prove the cnc machine hardware, I've repeated the install on an old pentium PC, connected to the same MESA card and CNC machine, and can successfully read the CPU speed, get an acceptable latency result, HAL monitor detects all switches correctly, and the machine jogs, homes and runs a small test peck drill task correctly.

So the mini-PC is the issue it seems. I'm hoping a setting or missing driver as all that needed for such things?

Would anyone have experience with running linuxcnc on an N100?  - does it even work for anyone?
    - (according to numerous threads here that I've collected advice from, seems it should!)

Figure I'm missing something obvious!

All photos: drive.google.com/drive/folders/1YG3q0ehZ...ZtYmPWzBao1RR8ckq3ZM 

Could you post your user command file and I will try to come up with something tomorrow afternoon. 

At the beginning all of them were set to 2A current to match steppers. Then I set Y axis driver to 2.5A and that's what you can see on the video.Regarding microstepping I've set it up to 8. 

Working on understanding the exact mesaflash/pncconf steps for setting up the firmware/linuxcnc associations for the
7i92T right now...

I got a copy of the "7i92t_7i85sx2d" zip file from mesanet on hand

Also, already went into pncconf to get an idea how THAT interface is handling this setup. It appears the discovery option
does identify the 7i92T (so that should mean the TRION fpga 7i92 is properly handled?), but once I get to the 7i85S an
"unsupported device" error is generated. Perhaps some sort of ini help file or other redirection method would be the solution
at this step. Maybe a one card at a time approach is also part of the method, still figuring out the specifics for this.

Considering the firmware may be handled at this stage, I am cautious of editing anything yet, but I suspect this shouldn't
be too difficult to accomplish, its just a matter of identifying what exactly needs modification and where...