I can fully agree, that the absolute position is far more important. One can use SSI2 variation for IncOders already. Thank you for fast BiSS firmware release :).
1 & 2) These makes sense. To avoid breaking compatibility we probably need user configurable option for that.
-
Good to know that. However, I think most elegant solution would be to write SimpleMotion driver for LinuxCNC. (I know itās not hard, I already have done that. However it is very unfinished).
-
That is intentional safety feature (i.e. if cable is disconnecter, or controller is dead, then motor will stand still). No change planned for now.
-
STO is hardware method, so itās not possible to make charge pump work on that. Looks like we need to update Granity not to give false impression that it would be possible.
-
Hmm, can you give an example how you would like to configure it?
-
This may be changed in a future FW. However, some delay will be there for noise/debounce filtering, and power stage needs time to charge bootstrap capacitors before it becomes operationalā¦
-
Thanks for pointing out, Wiki updated!
-
True, and itās doable. This is due to the fact that 3 phase steppers are pretty rare. Perhaps thatās the case because they give less torque per motor size compared to two phase steppers.
-
Encountered the same issue one day, that bug is now fixed at least in the latest version
-
Various improvements to scope feature have been made on latest FW beta and Granity. Now you for instance can use external trigger signal to record captures, or leave capture active while Granity is disconnected and check graphs later. Speed may be improved by settings USB serial converter latency to 1 ms from the detault 16 ms.
-
Thatās been also addressed in latest version
-
Thatās good idea. For now weāre improving documentation pages to make them clearer.
About sensor-less phasing - programmable phasing startup delay (maybe also speed) might be nice feature.
Example: slower movement might mitigate high stage inertia effects, different programmable delay of the phasing for different axis mitigate the effects of other stage movements at the same time. For heavily loaded direct drive systems the coupled simultaneous movement effects are strong.
That is a good request. Do you mean just a configurable delay parameter that drive will wait before doing anything? Iāll put it on my list.
The current solution to this problem is to control enable signals of the drives to have them initialize in wanted order. However, delay parameter might provide easier solution.
Just configurable delay before drive is to do anything is exactly it. The drive enables at different time method would not be easy option with IONICUBE X4 (all enables are connected together), do I understand correctly?
The phasing movement speed/acceleration configuration option (if it can be changed/reduced without hindering the working of the phase detection) would be separate; this might allow high mass stages.
Indeed, I think there is enough demand for such delay feature. Currently users who need sequenced initialization do it over SimpleMotion bus from a custom written application. However, this is not handy if SM API is not being used for control.
Phasing can be eliminated altogether by using Hall sensors. Most (say >95%) AC/BLDC servo motors have these signals available.
I assume IONI expects 120 degrees apart hall phase signals (not 60 deg)? I did not notice it mentioned in wiki currently.
Hi Tero. Any plans to support Tamagawa SSI? They have nice multi turn 23+16=39 bit abs encoder TS5700N5401 (1 at the end means made in china, Japanese one have 0 as last digit) that costs like 80USD and directly fits Mige motors. That could be ideal solution for crosstalk, resolution, homing and noise protection for Simucubeā¦
I really want to hear about this too.
Hi Tero!
Is there any update for the support of BiSS absolute encoders with no homing? The Orbis BR10DCA14B12BD00 from the wiki looks to be perfect for my application (a from scratch 6 axis robot arm). Although one of the key features we need is no homing routine, so currently this is the only thing holding us back from using IONIs.
Really like what you are doing here!
Dylan
Granite Devices for sure works on it 
I do not know where the firmware development is but this commit for sure allows no homing movements.
Ohhhhhh, good eye, thanks for the find!
Is sensorless closed loop driving of steppers still in the pipeline for IONI?
(http://openservodrive.com/atomi-closed-loop-cnc-stepper-controller/#comment-3812)
Nice work there, thank you! The 0 movement initialization using absolute encoder works well, good to have for motors without hall sensors :).
The SMP_ACTUAL_POSITION_FB_NEVER_RESETTING 906 should give the absolute encoder position now after turning on if I understand correctly?
(In simplemotion_defs.h:
SMP_ACTUAL_POSITION_FB_NEVER_RESETTING 906 /this is same than SMP_ACTUAL_POSITION_FB but does not reset to 0 on homing or init (it is always the original counter value at power-on)/")
Thanks for feedback! Indeed, it might be bit unlogical that param 906 is not absolute position. Iāll put it on my list of things to change.
Param 906 will be initialized with absolute reading in the next FW. Itās been already done, and if youāre curious, grab the following development snapshot FW that is V1.7.1 + above change = V1.7.44.
I hope this helps!
ioni_fw_10744.gdf (101.4 KB)
1 Like
Is that possible, that we can generate a ālagā for SimuCUBE. I know, that lags be things, that we donāt want. But with my wheel, i see, why another driver loos the cars because the āgaming-wheelsā has big lags. If i can set a synthetic lag, i can test that or show another people, what are the difference between gaming and DD-wheels. With TRF1 at 100, TRA1 at 0.33A, max Force 18,333% and 30 - 40ms outputlag, we can simulate a thrustmaster T500RS.
When its open (source), why not.
Hello Tero,
are now the right time for that feature, please?
Most likely such features are going to be implemented to SimuCUBE firmware, although basicly we will aim at reducing lag.