That is correct.
Although it can be triggered at other times as well.
Some people set it to trigger blade id when you switch presets.
That requires making some changes in the code.
1 Like
I’m certainly open to the idea of making changes in code anywhere that’s needed, and want to learn, but I’m afraid I don’t really understand how/where to do that. I also saw another thread where you mentioned possibly triggering blade ID with a button press (not when changing presets), which is an intriguing option too.
Can you please help me understand how I would set it up to trigger with a button press or when the preset changes, or direct me to a resource that can help?
I haven’t decided exactly how I want to proceed yet- I might still end up just going with blade detect, but I want to understand all my options, especially the ones that involve less wires lol
Basically, you would need to modify the event2 function in the prop class.
That function is responsible for specifying what happens for any button press.
Essentially all you would need to do is to insert a call to the FindBladeAgain() method somewhere and that will re-do the blade ID.
There is a pod page about making your own prop that might be relevant here:
I’m not exactly knowledgeable about terminology… Like this? (and if so, anything/what else?)
case EVENTID(BUTTON_AUX, EVENT_CLICK_SHORT, MODE_OFF):
#ifdef DUAL_POWER_BUTTONS
aux_on_ = true;
On();
#else
next_preset();
FindBladeAgain();
#endif
return true;
^^^just using the default saber.h file
Maybe… it depends on how much state is saved. If the current preset isn’t saved, then FindBladeAgain will reset back to the first preset, and next_preset() will essentially stop working.
So do I just need to define SAVE_STATE or SAVE_PRESET? What do you mean by “how much?” I hadn’t been thinking of it as a quantity, but maybe I’m just reading too much into this.
Apologies if this stuff is obvious, modifying the prop file is all very new to me beyond just changing button functionality. I really appreciate all the help you’ve been giving.
Well, SAVE_STATE includes SAVE_PRESET, so either would work.
We could also add some code that keeps track of the preset before and after in memory.
Now where it gets really tricky is that each blade can have it’s own preset array, and those arrays can be different sizes. Going from preset 4 to preset 5 makes perfect sense if you’re in the same blade ID, but if you switch to a different blade ID, you might find yourself with only 1 preset, and then going to preset 5 makes very little sense. It shouldn’t crash or anything, but it might be weird…
Okay, I think I like SAVE_PRESET better because I don’t really want color change mode to save. I’m glad to know that works, but yeah I can see how it could be weird.
I have the same number of presets in both arrays, so I’m hoping it will be fine without extra code. Regardless its good to know it wouldn’t have any serious issues, just the potential to be annoying. Thanks for your help!
Life got busy and I wasn’t able to finish my saber for a while, but now I have another question on this thread. Triggering Blade ID with a button press is working, but it cuts off whatever sound I have going as well. If I tie it to the same button press that changes the preset, it only plays part of the font announcement sound thingy (idk what to call that), and if I try it with turning the blade off, it cuts off the retraction sound. Is there any possible work around for this, or some way I can delay it so that it plays the full sound and then checks for blade ID?
Also, should I be using a blade ID class besides the default? I do not have an external pull-up resistor and I haven’t bridged anything, which is all the POD site mentions (unless I’m missing something…), but I’ve seen some people using snapshot blade ID? I 'm having trouble finding information on what that is and when it should be used.
We just went through a bunch of upgrade/testing with BladeID.
Check out this thread.
blade-id-scan-millis
Triggering blade ID while the blade is ON is not going to work well unless you add some code to make it happen in between blade updates, which is what the new BLADE_ID_SCAN_MILLIS define does.
As for which blade ID class to use: If the default (SnapshotBladeID) works well for you, then there is no reason to change it.
Documentation is an ongoing effort, but here’s some info to get it working for now:
- Set the following defines in your config
#define SHARED_POWER_PINS
#define ENABLE_POWER_FOR_ID PowerPINS<bladePowerPin2, bladePowerPin3> // Your LED pads may vary
#define BLADE_ID_CLASS SnapshotBladeID<bladeIdentifyPin>
#define BLADE_ID_SCAN_MILLIS 1000
#define BLADE_ID_TIMES 10
-
Hook up and check serial monitor during each state of blade/chassis/whatever inserted and removed and note the ID value scanned.
-
Then go back and edit your BladeConfig to use those values for the desired preset bank.
The post I linked above has more detail as that’s the exact process happening in there.
Oops, I didn’t realize SnapshotBladeID WAS the default. That’s… a helpful clarification lol.
I found the POD page for blade ID constant monitoring! I downloaded the OS7 alpha and did everything you said, and used the default prop file so it doesn’t check for blade ID with button presses anymore. Sound works correctly now, but it doesn’t seem to be switching to my “no blade” array, even when I toggle the kill switch. (Now that I think about it, I think this was happening before too, I just assumed something was wrong with the blade styles I made and not that it wasn’t switching arrays).
I haven’t checked the ID with the serial monitor yet (chassis has 2 segments that are held together in the hilt, but needs to be out to connect to computer, so its kind of tricky), so in the blade config my kr blade has a value of 0 and the “no blade” ID is 200000. Could that be why it isn’t switching, or is something potentially wrong?
You might want to try the define SAY_BLADE_ID.
That’s because I just made it lol.
Clarifying that it’s #define SPEAK_BLADE_ID
Okay, so I used the define to get some values. I didn’t know that was a thing and it made it much easier, thanks. Here’s what I got:
Chassis connected with blade in- 636 when saber is off, 638 when it is ignited
Chassis connected with no blade- 470
Main chassis section removed from hilt- around 418, but some fluctuation.
I put those values into my config (although I don’t currently have an array for chassis out, I just used the other 2), but I noticed something strange. With the blade out and saber off, my NPXL v3 connector flashes green for a moment. It seems to be about as often as it should be checking the ID (not 1000milliseconds, I slowed it down for now). Does this possibly have to do with it enabling power for ID? Any ideas on how I can make it stop flashing?
Actually, I changed it back to 1000 milliseconds. No more flashing… at first. Now its doing it again, more frequently (can be a second apart), but less consistently.
To clarify, before I had #define BLADE_ID_SCAN_MILLIS set to 10000. I tested it roughly with a stopwatch and it seemed to be flashing every 10 seconds.
This is a fairly generic (and somewhat hard to solve) problem with shared power pins.
The problem is that some neopixels will light up more or less immediately when powered on, and the only way to stop them is to send them some data very quickly after powering on.
In most cases, shared power pins still works ok, because we power the two blades which are sharing power pins at the same time.
Blade ID turns out the power pins without turning the blade on, which can trigger these sort of issues. The same kind of thing can happen to your main blade if it has pixels that turn on when powered.
I may be able to fix this, but it’s not trivial, so I’m not going to promise anything.