He has many usb devices. Button boxes etc.
I will have him disconnect everything else and re-test.
Hey Beano,
12.86amps for small mige.
I have the same drc loaded as I have used on many many controls.
One thing I did not mention is initially he had the motor power and estop cables reversed. Thank goodness the Simucube board protection circuits worked (THANKS Tero) board would not even power up.
After correcting the wiring control powered up.
I was on the phone / teamviewer with this guy for many hours! I am glad he is a nice guy!
Today, I got the new settings data format finished and the configuration tool works again, using the new data formats. Also wrote the converter function for old settings data to new format, and it works. Todo, is testing the writing new data to flash and loading it from there.
3 Likes
saving and loading data is also now tested.
Now I can actually develop a few new features - some for safety, some for functionality.
However, I currently can not safely push this current work to open source repository, but the repositories will get back in sync at a later date.
3 Likes
Mika , love your work ! Thumbs up
2 Likes
I also improved some things to be more future proof. 16 buttons sure is not enough.
2 Likes
How many buttons do we get!
Rotery’s and loadcel inputs that is what I want
then you can disconnect a few USB devices
Wich is beter for the USB problems wich Can occur
well, loadcell inputs would require loadcell amplifier hardware, which are not present on SimuCUBE. Loadcells work on very low voltage differences, and it is good practice to keep such signals very far from servo drives with high currents.
Rotary encoders are coming
1 Like
Yep, fully agreed with Mika, that’s why loadcell amps are generally mounted right next to pedals, for example, with high quality shielded cables, which are very short - and far away from servo and associated control electronics.
The high switching speed and currents involved going through Ioni mosfets will also cause disruptions to such small mV signals coming from loadcell, they typically range 1-2mV per volt, considering excitation voltage is usually 5V, you can imagine the noise susceptibility of a 5-10mV signal 
Cheers,
Beano
1 Like
Would it be OK to lock down the user-configurable analog axises to the first 4? This would simplify things in future.
- Yes
- No
0 voters
thanks for solid answer on that 
Today, I’ve ported the configuration tool to the new settings data format, and even did the first round of quality checkups and bug fixing for that. It would be possible to build this as a release, but there are no visible changes to the user at all yet.
I will add rotary encoder input options to the X12 inputs and then release
5 Likes
Today, I’ve implemented a new dialog for X12 inputs options. Those that want to prepare any cables and stuff, pinout will be:
Pin 1: button
Pin 2-3, 4-5, 6-7: three encoders
Pin 8: GND
and both X12 inputs can be selected separately to be either encoders (with one button, as above) or all buttons.
Edit: I meant to say that of course the code is also implemented in the upcoming 0.11 firmware!
I will need to wire an encoder to test this all…
1 Like
Hi Mika,
what kind of encoders are supported those with a pulse on every detent (eg ALPS 20-20) or a pulse on every second detent (ALPS 15-30)?
Is there any deglitching for the rotary encoders implemented - mechanical encoders usually have some glitches (at least the metal verdions of the ALPS ones I have) and you may recognize this easily while testing?
I use 2 in my bluetooth wheel and it took quite some time to get them working w/o the use of interrupts, as they are already needed for the communication between the arduino and the BT interface. At the end the only working solution was to implement a timeout of a few mSecs after each recognition of a state change on one of the two pins, what limits the max. rotation speed that is recognized.
Of course there would have been the possiblity of implemenation in hardware, but there wasn‘t sufficient space available at that time.
Regards
Guenther
The first version of the code, as it is now, is using the 10 ms debounced inputs as inputs to the encoder logic code.
I think the current encoders that we have at the office are Bourns PEC11R-4215F-S0012. Please look up what type these are and report back
edit: I think this would be 1 pulse per detent; and we have used the same encoders in another project so it is kind of known that these will work We also have 2 pulses per detent encoders at the office.
That one has 24 detents wirh 12 pulses, same as the ALPS STEC11B with its 30/15, so you are triggering on both the rising and falling edge to inc/dec on every detent.
Definitely people need to know that they have to use that kind of decoder.
We of course want and need to support both.
I have tested with the following encoder:
CTS 288V232R161B2
Could someone please link a similar encoder that has different pulses/detent mode, so we can then test and implement that too?
Can you test the Chinese cheap ones too?
I use them trough arduino buttonbox sketch
On a Nano micro and they work fine!
I cant see any numbers witch brand they are
Sorry, we don’t have chinese nobrand stuff in the office, and I do not have those at home either.