1. Forum
  3. Search

Advanced Search

Search Results (Searched for: )

  • TripleM
  • TripleM
Today 14:41
Replied by TripleM on topic Bitfile for Mesa 7i96s + 7i85 (+Modbus (PKT-Pin))

Bitfile for Mesa 7i96s + 7i85 (+Modbus (PKT-Pin))

Category: Driver Boards

The 7I84 is connected to 7I85 TB2 pins 10..16.

for test I have flashed the 7i96s + 7i85 firmware.

So I think this is the correct load line?!  Or have I misunderstood something?
loadrt hm2_eth board_ip="192.168.1.121" config="num_encoders=6 num_pwmgens=1 num_stepgens=9 sserial_port_0=x2xxxx"

Configuration Name: HOSTMOT2

General configuration information:

  BoardName : MESA7I96
  FPGA Size: 20 KGates
  FPGA Pins: 256
  Number of IO Ports: 3
  Width of one I/O port: 17
  Clock Low frequency: 100.0000 MHz
  Clock High frequency: 200.0000 MHz
  IDROM Type: 3
  Instance Stride 0: 4
  Instance Stride 1: 64
  Register Stride 0: 256
  Register Stride 1: 256

Modules in configuration:

  Module: DPLL
  There are 1 of DPLL in configuration
  Version: 0
  Registers: 7
  BaseAddress: 7000
  ClockFrequency: 100.000 MHz
  Register Stride: 256 bytes
  Instance Stride: 4 bytes

  Module: WatchDog
  There are 1 of WatchDog in configuration
  Version: 0
  Registers: 3
  BaseAddress: 0C00
  ClockFrequency: 100.000 MHz
  Register Stride: 256 bytes
  Instance Stride: 4 bytes

  Module: IOPort
  There are 3 of IOPort in configuration
  Version: 0
  Registers: 5
  BaseAddress: 1000
  ClockFrequency: 100.000 MHz
  Register Stride: 256 bytes
  Instance Stride: 4 bytes

  Module: OutM
  There are 1 of OutM in configuration
  Version: 0
  Registers: 1
  BaseAddress: B000
  ClockFrequency: 100.000 MHz
  Register Stride: 256 bytes
  Instance Stride: 4 bytes

  Module: PWM
  There are 1 of PWM in configuration
  Version: 0
  Registers: 5
  BaseAddress: 4100
  ClockFrequency: 200.000 MHz
  Register Stride: 256 bytes
  Instance Stride: 4 bytes

  Module: StepGen
  There are 9 of StepGen in configuration
  Version: 2
  Registers: 10
  BaseAddress: 2000
  ClockFrequency: 100.000 MHz
  Register Stride: 256 bytes
  Instance Stride: 4 bytes

  Module: MuxedQCount
  There are 6 of MuxedQCount in configuration
  Version: 4
  Registers: 5
  BaseAddress: 3600
  ClockFrequency: 100.000 MHz
  Register Stride: 256 bytes
  Instance Stride: 4 bytes

  Module: MuxedQCountSel
  There are 1 of MuxedQCountSel in configuration
  Version: 0
  Registers: 0
  BaseAddress: 0000
  ClockFrequency: 100.000 MHz
  Register Stride: 256 bytes
  Instance Stride: 4 bytes

  Module: SSerial
  There are 1 of SSerial in configuration
  Version: 0
  Registers: 6
  BaseAddress: 5B00
  ClockFrequency: 100.000 MHz
  Register Stride: 256 bytes
  Instance Stride: 64 bytes

  Module: SSR
  There are 1 of SSR in configuration
  Version: 0
  Registers: 2
  BaseAddress: 7D00
  ClockFrequency: 100.000 MHz
  Register Stride: 256 bytes
  Instance Stride: 4 bytes

  Module: InM
  There are 1 of InM in configuration
  Version: 0
  Registers: 5
  BaseAddress: 8500
  ClockFrequency: 100.000 MHz
  Register Stride: 256 bytes
  Instance Stride: 4 bytes

  Module: LED
  There are 1 of LED in configuration
  Version: 0
  Registers: 1
  BaseAddress: 0200
  ClockFrequency: 100.000 MHz
  Register Stride: 256 bytes
  Instance Stride: 4 bytes

Configuration pin-out:

IO Connections for TB3 -> 7I96_0
Pin#                  I/O   Pri. func    Sec. func        Chan     Sec. Pin func   Sec. Pin Dir

TB3-1                   0   IOPort       InM              0        Input0_EncA0    (In)
TB3-2                   1   IOPort       InM              0        Input1_EncB0    (In)
TB3-3                   2   IOPort       InM              0        Input2_EncA1    (In)
TB3-4                   3   IOPort       InM              0        Input3_EncB1    (In)
TB3-5                   4   IOPort       InM              0        Input4_EncA2    (In)
TB3-6                   5   IOPort       InM              0        Input5_EncB2    (In)
TB3-7                   6   IOPort       InM              0        Input6_EncA3    (In)
TB3-8                   7   IOPort       InM              0        Input7_EncB3    (In)
TB3-9                   8   IOPort       InM              0        Input8          (In)
TB3-10                  9   IOPort       InM              0        Input9          (In)
TB3-11                 10   IOPort       InM              0        Input10         (In)
TB3-13,14              11   IOPort       SSR              0        Out-00          (Out)
TB3-15,16              12   IOPort       SSR              0        Out-01          (Out)
TB3-17,18              13   IOPort       SSR              0        Out-02          (Out)
TB3-19,20              14   IOPort       SSR              0        Out-03          (Out)
TB3-21,22              15   IOPort       OutM             0        Output4         (Out)
TB3-23,24              16   IOPort       OutM             0        Output5         (Out)

IO Connections for TB1/TB2 -> 7I96_1
Pin#                  I/O   Pri. func    Sec. func        Chan     Sec. Pin func   Sec. Pin Dir

TB1-2,3                17   IOPort       StepGen          0        Step/Table1     (Out)
TB1-4,5                18   IOPort       StepGen          0        Dir/Table2      (Out)
TB1-8,9                19   IOPort       StepGen          1        Step/Table1     (Out)
TB1-10,11              20   IOPort       StepGen          1        Dir/Table2      (Out)
TB1-14,15              21   IOPort       StepGen          2        Step/Table1     (Out)
TB1-16,17              22   IOPort       StepGen          2        Dir/Table2      (Out)
TB1-20,21              23   IOPort       StepGen          3        Step/Table1     (Out)
TB1-22,23              24   IOPort       StepGen          3        Dir/Table2      (Out)
TB2-2,3                25   IOPort       StepGen          4        Step/Table1     (Out)
TB2-4,5                26   IOPort       StepGen          4        Dir/Table2      (Out)
TB2-7,8                27   IOPort       MuxedQCount      2        MuxQ-A          (In)
TB2-10,11              28   IOPort       MuxedQCount      2        MuxQ-B          (In)
TB2-13,14              29   IOPort       MuxedQCount      2        MuxQ-IDX        (In)
TB2-16,17              30   IOPort       SSerial          0        RXData0         (In)
TB2-18,19              31   IOPort       SSerial          0        TXData0         (Out)
Internal-TXEn          32   IOPort       SSerial          0        TXEn0           (Out)
Internal               33   IOPort       SSR              0        AC Ref          (Out)

IO Connections for P1 -> 7I96_2
Pin#                  I/O   Pri. func    Sec. func        Chan     Sec. Pin func   Sec. Pin Dir

P1-01/DB25-01          34   IOPort       SSerial          0        RXData5         (In)
P1-02/DB25-14          35   IOPort       SSerial          0        TXData5         (Out)
P1-03/DB25-02          36   IOPort       SSerial          0        RXData4         (In)
P1-04/DB25-15          37   IOPort       SSerial          0        TXData4         (Out)
P1-05/DB25-03          38   IOPort       SSerial          0        RXData3         (In)
P1-06/DB25-16          39   IOPort       SSerial          0        TXData3         (Out)
P1-07/DB25-04          40   IOPort       SSerial          0        RXData2         (In)
P1-08/DB25-17          41   IOPort       SSerial          0        TXData2         (Out)
P1-09/DB25-05          42   IOPort       SSerial          0        RXData1         (In)
P1-11/DB25-06          43   IOPort       SSerial          0        TXData1         (Out)
P1-13/DB25-07          44   IOPort       MuxedQCountSel   0        MuxSel0         (Out)
P1-15/DB25-08          45   IOPort       MuxedQCount      0        MuxQ-A          (In)
P1-17/DB25-09          46   IOPort       MuxedQCount      0        MuxQ-B          (In)
P1-19/DB25-10          47   IOPort       MuxedQCount      0        MuxQ-IDX        (In)
P1-21/DB25-11          48   IOPort       MuxedQCount      1        MuxQ-A          (In)
P1-23/DB25-12          49   IOPort       MuxedQCount      1        MuxQ-B          (In)
P1-25/DB25-13          50   IOPort       MuxedQCount      1        MuxQ-IDX        (In)

 
  • vibram
  • vibram
Today 14:27
El5101 possible overflow? was created by vibram

El5101 possible overflow?

Category: EtherCAT

Hello 
I have a spindle encoder with a quadrature signal. 
It will be wired to a El5101 but I'm worried about a possible variable overflow as I have 2000 ppr and my spindle can go up to 3000rpm. 
I don't think I'm the first one in this situation. How I can handle it? 

Thank you for your help 
  • rodw
  • rodw's Avatar
Today 11:26
Replied by rodw on topic LinuxCNC S-Curve Accelerations

LinuxCNC S-Curve Accelerations

Category: General LinuxCNC Questions

I really think this discussion of latency is irrelevant. I've had my doubts about 2 core CPU's being adequate for a few years but with careful tuning they work for some.

Either the latency is acceptable or it isn't on a specific PC. There is no hard and fast rule for what is acceptable.You all seem to be working with ethercat or Mesa devices so system latency is no longer relevant if the  system is correctly set up to minimize system processes that cause periodic latency spikes.

Network latency is a fairly new concept for Linuxcnc users and has only been an issue since the release of Debian Bullseye but that coincides with increased power saving technology and an insistence by kernel developers to use fully open source network drivers and not incorporate the Realtek DKMS drivers where full source is not available.

I really would like to see actual results discussed,  not theoretical dicussions about what might work and what might not. From kernel traces, I know there is a spare 800 ns on most systems before latency will be an issue. I am sure that is more than enough to support any additional processing.
  • unknown
  • unknown
Today 10:50
Replied by unknown on topic RPi CM5 on Mesa Ethernet 7i95

RPi CM5 on Mesa Ethernet 7i95

Category: General LinuxCNC Questions

Please use this image:
drive.google.com/file/d/1CoO_2y7iDTwtubG...VSw/view?usp=sharing

Usually a no carrier issue would be a cable issue between the RPi5 & Mesa board (the drivers have been loaded), has the Mesa board booted correctly ?

Bear in mind that the kernel used is directly from the Raspberry Pi repos, ie it is not a custom kernel other than being RT capable. The RPi kernel build instruction make no differentiation between any of the "5" series. The all use the same kernel. Neither is there special options related to ethernet for the CM5 in the config.txt file.

It may help if you can provide a link to the carrier board.

The best place for any issues relating to the current Trixie images is at the link below as I don't use the forum as often as I used to. There is no need to raise an issue as I'm aware of it.
github.com/ozzyrob/linuxcnc-rpi-2.9.7-image-issues
  • grandixximo
  • grandixximo's Avatar
Today 09:00 - Today 09:06
Replied by grandixximo on topic LinuxCNC S-Curve Accelerations

LinuxCNC S-Curve Accelerations

Category: General LinuxCNC Questions

We have our own proprietary protocol, but you can take a look at this, it's very similar to our own work:

linuxcnc.org/docs/2.8/html/man/man1/linuxcncrsh.1.html

It's all good and well, but let's try to stay on topic, I'm more interested in tp0 vs tp1 issues, or other S-curve/blending related topics.
  • zmrdko
  • zmrdko's Avatar
Today 08:49
Replied by zmrdko on topic LinuxCNC S-Curve Accelerations

LinuxCNC S-Curve Accelerations

Category: General LinuxCNC Questions

Hello grandixximo,

amazing work, I have cloned your repo and tested rip install on my i7 9700k.
I have just read in your last post, that you are using external UI, which is brilliant idea - to offload system running linuxcnc and use UI on another PC.
Can you share some details, if it's possible?

Thank you very much for you work, time and effort.
  • endian
  • endian's Avatar
Today 08:24
Replied by endian on topic LinuxCNC S-Curve Accelerations

LinuxCNC S-Curve Accelerations

Category: General LinuxCNC Questions

Yes Michel did amazing job ... I have been in touch with him few months ago and he knows about the situation of his scurve too .. We have testing it long time and talking about the possible solutions but he is down for now ... 

Can you share some details of hints to best hardware performace at your side please?

 
  • grandixximo
  • grandixximo's Avatar
Today 08:17 - Today 08:30
Replied by grandixximo on topic LinuxCNC S-Curve Accelerations

LinuxCNC S-Curve Accelerations

Category: General LinuxCNC Questions

Our S-Curve code has almost nothing to do with what Grotius did, we have been working on this long before Grotius started on it, we have read Grotius reference material, and followed Grotius progress, and took some inspiration for some refining of our original code we were testing, and we are very grateful for his work, but you cannot compare our S-Curve to Grotius's one.

The testing that you can report to us are to be done with the latest code from github, on my fork of linuxcnc
github.com/grandixximo/Linuxcnc-G-code
You have to provide pictures or written comparison with planner_type 1 and with planner_type 0
Then we will try to reproduce on our end, and see if we can fix whatever the issue might be.

Edit:
As far as hardware goes, we had been running intel G2030 CPUS for many years with mesa PCI LPT and realtek network with mesa_eth cards, but these systems are now very hard to come by, we work now with NUCS, and have used N100 and now N150 based SBC's with intel i225 (igc) for good ethercat  latency, we are probably around 20us latency (which I'm not super happy with), but mind that we do not run much of anything but mate-debian ethercat-master and linuxcnc, not even axis UI runs on our systems, we have our own remote UI.
  • endian
  • endian's Avatar
Today 08:13
Replied by endian on topic LinuxCNC S-Curve Accelerations

LinuxCNC S-Curve Accelerations

Category: General LinuxCNC Questions

I definitely agree with your opinion ... therefore I have testing at CoreDuo, i5 and i7 too ... and then just share my observation 

As I said before I am not expert of this topic but it is very interesting to help if there is a play to ...

can you share your hardware setup with us which is the best to avoid spiking please?

 
  • grandixximo
  • grandixximo's Avatar
Today 08:07
Replied by grandixximo on topic LinuxCNC S-Curve Accelerations

LinuxCNC S-Curve Accelerations

Category: General LinuxCNC Questions

Yes, I think I understand you better now. Still you asked me what I would be doing about the spiking, and in my testing there is no spiking that I should be doing anything about, at least as far as the code we have contributed, and as far as my testing shows to me, but I am open to different hardware having different reactions to the algorithms, but this has to be empirically shown to be true with a test similar to mine, it is easy to introduce third variables unintentionally, so any testing has to be done with the least variation as possible, try to change only planner_type 0 to planner_type 1
This toggle exist exactly for the purpose of quick comparison between original trapez vs new s-curve.
  • endian
  • endian's Avatar
Today 07:58 - Today 08:07
Replied by endian on topic LinuxCNC S-Curve Accelerations

LinuxCNC S-Curve Accelerations

Category: General LinuxCNC Questions

I think we are not understanding us now ... I just share latency histogram to just prove my RT and latency free setup(eliminate hardware setup source), not to share pictute of spikes of my latency... I defenetly know that latency histogram and scope are two different things but over histogram we are fast and visible proving our setup of RT... 

here is scope of Intel core duo and AI tells me that Intal core duo has not some hardware instructions which can cause overloading from time to time ... here was most visible spiking 

Edit > yes my testing was doing exactly as you are talking ... first test was 3 phase and the 7phase generator .. 

it was just testing after experience with scurve of grotius where spiking what much greater and creating time lagging during cloud of point movement ... this situation is now not present at all I think, it works really well .. motion is excelent 

great job ! I am amazed.
  • JanCNC
  • JanCNC
Today 07:53 - Today 08:32
Replied by JanCNC on topic Servos drives directly start turning

Servos drives directly start turning

Category: General LinuxCNC Questions

No, the servo drives of the Y-Gantry each have their own connection to the encoder TB3/4 and analog interface TB5.
Attached is a picture of my 7i77 axis connection.

If I connect only one of the two Y axes to the analog interface TB5 and enable with F2 the axis enters control mode (drifting slightly but no jog possible). However, if I connect both axes to TB5 and enable them with F2, the axes immediately spin at high speed and a following error occurs.

@PCW What do you mean with "test  this with the linear axis disconnected"?

Note: The axes are currently not connected to the mechanics and are essentially lying loose on the table.


 
  • grandixximo
  • grandixximo's Avatar
Today 07:42 - Today 07:59
Replied by grandixximo on topic LinuxCNC S-Curve Accelerations

LinuxCNC S-Curve Accelerations

Category: General LinuxCNC Questions

Spikes when you run latency-histogram are caused by the CPU doing other stuff, like checking the network status, reading your mouse and keyboard inputs, display graphical elements, going to sleep because its got nothing to do.
This is not in topic of this discussion about s-curve

Edit:
My test methodology was analytical, I ran same g-code, on same machine, same halscope size, changed the least variables as possible, only planner_type 0 vs planner_type 1
Please in future if anyone wants to bring forth issues about our s-curve implementation, they should use similar testing methodology, during our own internal testing of the S-curve calculations, we also often forgot to do this straight fair comparison, and it sent us on wild goose chases. Mind that we are aware that there are blending issues, this is something that we are working on, but these issues persist in both planner_types. Therefore please try to compare planner_type 0 vs planner_type 1 without changing anything else before bringing forward issues.
  • endian
  • endian's Avatar
Today 07:36
Replied by endian on topic LinuxCNC S-Curve Accelerations

LinuxCNC S-Curve Accelerations

Category: General LinuxCNC Questions

I have just posted the latency of my system in the case of checking and searching spikes source... 

Oooo it amazing to find that checking a scope is a source of spiking itself... thank you for briliant observation!
  • grandixximo
  • grandixximo's Avatar
Today 07:24 - Today 07:33
Replied by grandixximo on topic LinuxCNC S-Curve Accelerations

LinuxCNC S-Curve Accelerations

Category: General LinuxCNC Questions

Yes I just finished testing, and our S-Curve acc tp seems to be computationally better, and spiking less the servo thread compared to the original trapez acc tp, as far as I see, thanks to our work you are getting a better and more computationally efficient TP with planner_type = 1 

Now I'm a bit confused about what spikes you want me to fix, the pictures you sent are of the latency-histogram, which I think you cannot even run when you are running linuxcnc, interpreting gcodes, and actually run our code the new s-curve acc tp, planner_type = 1

I think you might have some misunderstanding of where our S-Curve lives within the LinuxCNC architecture, we only changed the TP which stands for the Trajectory Planner. The Trajectory Planner is not calculating anything when you run latency-histogram, whatever spikes you see in latency-histogram have no connection with the Trajectory Planner, does that clear things up? Or is there something I'm missing? Am I misinterpreting you? Or am I missing something else?

Edit:
On our system I see way more spikes when moving windows around, opening glxgears, or even simply having halscope in view rolling the servo-thread, when halscope is minimized I have way less spikes to 20k compared to when I run either g-code you supplied. There is a catch I can only see that I was having less spikes AFTER I restore halscope in view, and then the spikes start again, making me conclude that the act of checking the spikes with halscope introduces more spikes than anything we are doing with the S-curve or trapez TPs, but I repeat in my testing our S-curve is more computationally efficient than normal trapez TP
Displaying 1 - 15 out of 280921 results.
  1. Forum
  3. Search
Time to create page: 1.477 seconds
Powered by Kunena Forum