BasicMicroUK - Forums

Interesting. This seems the answer to my previous question, but will the command stay active if you keep the key pressed?

I am beggining to work with you code now.

No, it repeats.
This is why you would add a simple redundancy check.
IE if the repeated command is the same as before, to just skip and wait for the next command.
Getting the timing right will be a bit tricky, my biggest issue was the fact the first repeate is different than the other repeats, so with the timing of like 250ms, your bot will keep doing what it was doing for a full 250ms after you stopped sending commands.
You may even have to switch to hserial for commands, which uses TTL signals so you may need yet another converter RS-232 to TTL.

The echo should have no effect on the commands.


I can't help with the RJ45/serial converter, as i simply don't have one to play with, any help i give you, is what i would get from the manual.

Br@y++'s terminal program doesn't always like virtual serial ports.. The only time it works with bluetooth serial ports is if i use bluesoleil as the stack, and even then it has problems.

It looks like Br@y++'s terminal program was the issue with not being able to sending commands via the virtual port. I tried another program (Device Terminal V 1.0 referred to by converter manufacturer...WizNet) and it worked.

To get to this point, I uploaded code (via serial cable first) to the Pro28 that would continually broadcast a message, then determined that the message was being received by the Br@y++ terminal. Then I swapped from Serial Cable to the Cat5e configuration and repeated the test to receive the broadcast. No joy.

Next, I temporarily switched back to serial cable connection to upload keypad control program from before, then switched back to Cat5e for operation. Using the Device Terminal V1.0, commands are being received by the rover. No macro capabilities with the terminal program, but I was thinking to go back to Flowstone now.

Whatta relief to know that the Cat5e configuration can work.

On to refining the keypad (or other) control method and testing the limits of wired Cat5e control (+300').

Thank you.

About your earlier post of dec and dec2 being 1 digit and 2 digits.
dec2 will expect 2 digits, but dec will work for a full range.
If you want a single digit, you use dec1

Example

dec3 cat, dec1 horse, dec2 dog, dec fox

and you send

1234567890

cat = 123
horse = 4
dog = 56
fox = 7890 ;what ever is left


So if you want to control 2 tracks using 2 sets of 3, you need a 0.
IE left track and right track, if you both want them to = 50
then it would be
dec3 Ltrack, dec3 rtrack

send = 050050

then each one will get 050

This is how my universal controller works, it just sends a long sting of numbers, and the dec3 or label\3 separates them, and assigns the different sections into their own variable labels.
Really quite convenient.
Using this type of assignment is fantastic as you can make a simple to transmit code that can transmit long distances safely.

By adding a safety check, you get stop any missing bytes from goofing you up. such as with my rover claw.bas file.



This literally checks for any goof code. Though really the values for Rx etc shouldn't go above 1023 for me.

I'll be watching this thread, i'm very interested to see the outcome.

Update on control testing with keys and switching to Cat5e control:

My current critical issues are in bold.

The following code is a second attempt at sending mixed mode and speed commands to the RoboClaw (via Pro28) so that motors turn when a key is pressed and motors stop when it is released. I am happy to say it works fairly well and is smooth.

The previous code attempt was more complex as I used IF statements (like fool-goof code suggested earlier) to determine if a different key was pressed (ie different key = command or speed). It was working okay, but I started over from scratch which resulted in the following code.



In both attempts, there is a very slight hiccup after a key is pressed (ex key pressed -> motor turn -> minor pause -> motors continue). Is the hiccup related to Fallentine's reference below? Also, the timing is tricky as suggested by Fallentine. I tinkered with the 'pauseus' location and duration a great deal (pauseus 100000). The current setup is the smoothest and most responsive yet. Can it be improved? I also discovered that it is very important to send a 'full stop' command to transition between mix mode commands (refer to code where speed = 0).



Also, the RS232/RJ45 converter is working so I can communicate with Cat5e. Unfortunately, Terminal by Br@y doesn't work with virtual com port so I am still using serial cable when testing using terminal macros. Hopefully, Flowstone will solve the issue so I can send macro commands via Cat5e. Can anyone recommend a flowstone example which might kickstart sending macros over virtual com port or via network connection? The following Flowstone applications (macro.exe or lynxmotionminiterminal.fsm) don't seem to work with virtual com port (?!?). I am playing around with Flowstone and reverse engineering samples to acheive basic communication over Cat5e. Then I can eliminate the serial cable, except when programming with BasicMicro Studio.

Mike

RoboClaw Mixed Mode being used:
Key Action Command Speed Value Range
F1 Turn Left 11 0-127
F2 Both Forward 08 0-127
F3 Turn Right 10 0-127
F14 Backward 09 0-127


Sample Macro Format being used: (two-digit command then three digit speed)
11064
08064
10064

Main

Serin s_in, i38400, 300000, Main, [dec2 Command, dec3 Speed]

100000 = 50ms,
300,000 = 150ms, it needs a bit of breathing room.

When using hserial and software serial together, give it a tiny bit of breathing room, add a 1ms pause after EACH serout command, may it be software or hardware.

hserout blah blah
pause 1

Don't ask me why, i don't know, but 90% of my serial problems are timing related.
Been a bit sick so i can't really focus to much, this is the first time i've been on my pc in like a week.

I have definitely seen what you mean regarding timing impacts. I will tweak as you suggested. Stay tuned.

I am also struggling with getting flowstone to send strings repeatedly. It only sends them once when I activate a trigger. Any suggestions are welcom. I am playing around with samples and from-scratch configurations in Flowstone. Hopefully, I get smarter or lucky. I am counting on the latter.

Would it be benefcial to post the *.fsm file?

Thank's for taking time to respond while you're recovering. I wish you well in getting un-sick.

Mike

Right now i have no way of testing anything, the flowstone subforum over at lynxmotion.net is the place you want to ask in regards to flowstone.

That makes sense. I will reach out on that forum.

Thanks.

Update:

Flowstone
I really couldn't develop simple configurations and modify samples to reliably send commands via any com port (serial cable or virtural). I had it working for about 20 mins, but couldn't repeat the behavior after further testing. This drove me back to trying Terminal by Br@y++ which I thought was having issues with using virtual com ports. I did the following and it NOW works...

Test 1: Rover Broadcasts String Message (ex. "Hello")
With code uploaded, I was able to receive the message in the terminal window.

Test 2: Rover Receives String Command (ex 08084 -> command = 2 digits, speed = 3 digits)
With code uploaded, the motors did not turn when I sent a string command from the terminal via a macro.

Test 3: Merge Broadcast and Receive Code
With code uploaded, the motors turn as they should and I receive two strings and variables (ex Command: 8 Speed: 84) in the terminal. Success!!

Question: Why would merging the code fix the problem and motors turn? Does a pin (or the serial port) need to be configured to simulate what is happening in Test 3? Polling? Interrupts?

Question: Any suggestions to eliminate the motors running uncontrollablly if I press two keys in close succession or at the same time? I have to be careful not to move between key presses too quickly. If I purposely hit two directions at once (ie two macro function keys) the RoboClaw starts turning the motors and doesn't stop until I hit another direction. That is unwanted behavior. The code is set to send a stop command if the Serin command times-out and no command is received. It seems the RoboClaw is crashing (??) because of the data mix resulting from pressing two keys at the same time or very close together. The orange light on RoboClaw is blinking and the Green Light is blinking. Will your fool-goof code from the earlier post solve this issue? Can I add or modify a pause to make the system more forgiving in the event I hit two keys close together or at the same time?

Also, I mentioned previously that a short hiccup would occur in the initial motor turn after the key was pressed and held. I realized that the rythym was the same as if you held down the letter 'A'. Initially one A......pause.......repeat AAAAAA's. I think the hiccup is related to the 'key press repeat delay'. I gathered more evidence by opening the 'set macros' dialougue. When I would check the 'repeat' box next to one of the macro commands, motors would turn immediately. I tried to minimize the delay in Control Panel and even confirmed the registry value for the 'repeat delay' = 0. Is there another way to eliminate the 'key press repeat delay'. I think that would minimize the hiccup.

Mike

Current Code Attached

Any feedback on the 'hiccup' and the 'rapid-key-press' error?

I have confirmed the hiccup is related to the 'key repeat delay' by connecting an LED to a Basic Micro switch (Bit Switch), then using the terminal program to send a macro command (sending 1 gets added to # then A to turn light on). AFter pressing and holding a key, the light turns on....pauses (turns off), then turns on again. The SAME hiccup as the motors previously mentioned. It's definitely something with the 'key repeat delay'.